diff mbox series

[v2,1/3] dt-bindings: platform: Add bindings for Qcom's EC on IT8987

Message ID 20241219200821.8328-1-maccraft123mc@gmail.com
State New
Headers show
Series [v2,1/3] dt-bindings: platform: Add bindings for Qcom's EC on IT8987 | expand

Commit Message

Maya Matuszczyk Dec. 19, 2024, 8:08 p.m. UTC
This patch adds bindings for the EC firmware running on IT8987 present
on most of X1E80100 devices

Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
---
 .../bindings/platform/qcom,x1e-it8987-ec.yaml | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml

Comments

Aiqun(Maria) Yu Dec. 20, 2024, 11:50 a.m. UTC | #1
On 12/20/2024 4:58 AM, Maya Matuszczyk wrote:
> czw., 19 gru 2024 o 21:43 Bryan O'Donoghue
> <bryan.odonoghue@linaro.org> napisał(a):
>>
>> On 19/12/2024 20:08, Maya Matuszczyk wrote:
>>> Currently it features only reporting that the AP is going to suspend,
>>> which results in keyboard backlight turning off and the power LED
>>> slowly blinking on the Lenovo Yoga Slim 7x.
>>>
>>> Honor Magicbook Art 14 and Lenovo Yoga Slim 7x are known to have
>>> firmware with extensions which would need appropriate handling.
>>> For reverse engineering the firmware on them I have written a Rust
>>> utility:
>>>
>>> https://github.com/Maccraft123/it8987-qcom-tool.git
>>>
>>> Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
>>> ---
>>>   MAINTAINERS                              |   6 +
>>>   drivers/platform/arm64/Kconfig           |   8 ++
>>>   drivers/platform/arm64/Makefile          |   1 +
>>>   drivers/platform/arm64/qcom-x1e-it8987.c | 158 +++++++++++++++++++++++
>>>   4 files changed, 173 insertions(+)
>>>   create mode 100644 drivers/platform/arm64/qcom-x1e-it8987.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index b878ddc99f94..08d170e2e1e3 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -12890,6 +12890,12 @@ S:   Maintained
>>>   W:  http://legousb.sourceforge.net/
>>>   F:  drivers/usb/misc/legousbtower.c
>>>
>>> +QCOM IT8987 EC DRIVER
>>> +M:   Maya Matuszczyk <maccraft123mc@gmail.com>
>>> +S:   Maintained
>>> +F:   Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml

Actually, the IT8987 is from ITE Tech. As far as I know, there are other
platforms besides x1e that use this. So if this driver can be also
applied for all ITE it8987, it might be better to say 'ITE IT8987'
instead of 'QCOM IT8987'. This also applies to the file name and function.
>>> +F:   drivers/platform/arm64/qcom-x1e-it8987.c
>>> +
>>>   LETSKETCH HID TABLET DRIVER
>>>   M:  Hans de Goede <hdegoede@redhat.com>
>>>   L:  linux-input@vger.kernel.org
>>> diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
>>> index f88395ea3376..ebb7b4f70ca0 100644
>>> --- a/drivers/platform/arm64/Kconfig
>>> +++ b/drivers/platform/arm64/Kconfig
>>> @@ -49,4 +49,12 @@ config EC_LENOVO_YOGA_C630
>>>
>>>         Say M or Y here to include this support.
>>>
>>> +config EC_QCOM_X1E_IT8987
>>> +     tristate "Embedded Controller driver for most X1E80100 laptops"
>>> +     depends on ARCH_QCOM || COMPILE_TEST
>>> +     depends on I2C
>>> +     help
>>> +       This driver currently supports reporting device suspend to the EC so it
>>> +       can take appropriate actions.
>>> +
>>>   endif # ARM64_PLATFORM_DEVICES
>>> diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
>>> index b2ae9114fdd8..b9aa195bc1e6 100644
>>> --- a/drivers/platform/arm64/Makefile
>>> +++ b/drivers/platform/arm64/Makefile
>>> @@ -7,3 +7,4 @@
>>>
>>>   obj-$(CONFIG_EC_ACER_ASPIRE1)       += acer-aspire1-ec.o
>>>   obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
>>> +obj-$(CONFIG_EC_QCOM_X1E_IT8987) += qcom-x1e-it8987.o
>>> diff --git a/drivers/platform/arm64/qcom-x1e-it8987.c b/drivers/platform/arm64/qcom-x1e-it8987.c
>>> new file mode 100644
>>> index 000000000000..d27067d6326a
>>> --- /dev/null
>>> +++ b/drivers/platform/arm64/qcom-x1e-it8987.c
>>> @@ -0,0 +1,158 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) 2024 Maya Matuszczyk <maccraft123mc@gmail.com>
>>> + */
>>> +#include <linux/i2c.h>
>>> +#include <linux/module.h>
>>> +#include <linux/input.h>
>>> +#include <linux/input/sparse-keymap.h>
>>
>> Your includes should be alphabetised.
>>
>>> +
>>> +#define EC_IRQ_REASON_REG 0x05
>>> +#define EC_SUSPEND_RESUME_REG 0x23
>>> +#define EC_IRQ_ENABLE_REG 0x35
>>> +
>>> +#define EC_NOTIFY_SUSPEND_ENTER 0x01
>>> +#define EC_NOTIFY_SUSPEND_EXIT 0x00
>>> +#define EC_NOTIFY_SCREEN_OFF 0x03
>>> +#define EC_NOTIFY_SCREEN_ON 0x04
>>> +
>>> +#define EC_IRQ_MICMUTE_BUTTON 0x04
>>> +#define EC_IRQ_FAN1_STATUS_CHANGE 0x30
>>> +#define EC_IRQ_FAN2_STATUS_CHANGE 0x31
>>> +#define EC_IRQ_FAN1_SPEED_CHANGE 0x32
>>> +#define EC_IRQ_FAN2_SPEED_CHANGE 0x33
>>> +#define EC_IRQ_COMPLETED_LUT_UPDATE 0x34
>>> +#define EC_IRQ_COMPLETED_FAN_PROFILE_SWITCH 0x35
>>> +#define EC_IRQ_THERMISTOR_1_TEMP_THRESHOLD_CROSS 0x36
>>> +#define EC_IRQ_THERMISTOR_2_TEMP_THRESHOLD_CROSS 0x37
>>> +#define EC_IRQ_THERMISTOR_3_TEMP_THRESHOLD_CROSS 0x38
>>> +#define EC_IRQ_THERMISTOR_4_TEMP_THRESHOLD_CROSS 0x39
>>> +#define EC_IRQ_THERMISTOR_5_TEMP_THRESHOLD_CROSS 0x3a
>>> +#define EC_IRQ_THERMISTOR_6_TEMP_THRESHOLD_CROSS 0x3b
>>> +#define EC_IRQ_THERMISTOR_7_TEMP_THRESHOLD_CROSS 0x3c
>>> +#define EC_IRQ_RECOVERED_FROM_RESET 0x3d

Could you provide more details or any document references for the IRQ
reasons defined above? It seems incomplete to me.
By the way, I noticed this is a V2, but I couldn't find V1. Perhaps
including a cover letter next time would be helpful.
>>> +
>>> +struct qcom_x1e_it8987_ec {
>>> +     struct i2c_client *client;
>>> +     struct input_dev *idev;
>>> +     struct mutex lock;
>>> +};
>>> +
>>> +static irqreturn_t qcom_x1e_it8987_ec_irq(int irq, void *data)
>>> +{
>>> +     struct qcom_x1e_it8987_ec *ec = data;
>>> +     struct device *dev = &ec->client->dev;
>>> +     int val;
>>> +
>>> +     guard(mutex)(&ec->lock);
>>
>> What's the thing that can execute at the same time as this procedure -
>> there doesn't appear to be any concurrent candidate in this patch.
> The user could suspend the laptop and the EC could fire an IRQ at the same
> time... I'll need to add mutex locking to suspend/resume functions
> 

Using a mutex lock inside an IRQ handler is not advisable. Additionally,
since this IRQ appears to be only for logging purposes, is it really
necessary for it to be triggered during suspend and resume?
> 
>>> +
>>> +     val = i2c_smbus_read_byte_data(ec->client, EC_IRQ_REASON_REG);
>>> +     if (val < 0) {
>>> +             dev_err(dev, "Failed to get EC IRQ reason: %d\n", val);
>>> +             return IRQ_HANDLED;
>>> +     }
>>> +
>>> +     dev_info(dev, "Unhandled EC IRQ reason: %d\n", val);
>>
>> Should an unhandled IRQ be an info or an err ?
> I don't know, it's "unimplemented but doesn't really matter"
> 
>>
>>> +
>>> +     return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int qcom_x1e_it8987_ec_probe(struct i2c_client *client)
>>> +{
>>> +     struct device *dev = &client->dev;
>>> +     struct qcom_x1e_it8987_ec *ec;
>>> +     int ret;
>>> +
>>> +     ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
>>> +     if (!ec)
>>> +             return -ENOMEM;
>>> +
>>> +     mutex_init(&ec->lock);
>>> +     ec->client = client;
>>> +
>>> +     ret = devm_request_threaded_irq(dev, client->irq,
>>> +                                     NULL, qcom_x1e_it8987_ec_irq,
>>> +                                     IRQF_ONESHOT, "qcom_x1e_it8987_ec", ec);
>>> +     if (ret < 0)
>>> +             return dev_err_probe(dev, ret, "Unable to request irq\n");
>>> +
>>> +     ret = i2c_smbus_write_byte_data(client, EC_IRQ_ENABLE_REG, 0x01);
>>> +     if (ret < 0)
>>> +             return dev_err_probe(dev, ret, "Failed to enable interrupts\n");
>>> +
>>> +     return 0;
>>> +}
>>> +
>>> +static void qcom_x1e_it8987_ec_remove(struct i2c_client *client)
>>> +{
>>> +     struct device *dev = &client->dev;
>>> +     int ret;
>>> +
>>> +     ret = i2c_smbus_write_byte_data(client, EC_IRQ_ENABLE_REG, 0x00);
>>> +     if (ret < 0)
>>> +             dev_err(dev, "Failed to disable interrupts: %d\n", ret);
>>> +}
>>> +
>>> +static int qcom_x1e_it8987_ec_suspend(struct device *dev)
>>> +{
>>> +     struct i2c_client *client = to_i2c_client(dev);
>>> +     int ret;
>>> +
>>> +     ret = i2c_smbus_write_byte_data(client, EC_SUSPEND_RESUME_REG, EC_NOTIFY_SCREEN_OFF);
>>> +     if (ret)
>>> +             return ret;
>>> +
>>> +     ret = i2c_smbus_write_byte_data(client, EC_SUSPEND_RESUME_REG, EC_NOTIFY_SUSPEND_ENTER);
>>> +     if (ret)
>>> +             return ret;
>>> +
>>> +     return 0;
>>> +}
>>> +
>>> +static int qcom_x1e_it8987_ec_resume(struct device *dev)
>>> +{
>>> +     struct i2c_client *client = to_i2c_client(dev);
>>> +     int ret;
>>> +
>>> +     ret = i2c_smbus_write_byte_data(client, EC_SUSPEND_RESUME_REG, EC_NOTIFY_SUSPEND_EXIT);
>>> +     if (ret)
>>> +             return ret;
>>> +
>>> +     ret = i2c_smbus_write_byte_data(client, EC_SUSPEND_RESUME_REG, EC_NOTIFY_SCREEN_ON);
>>> +     if (ret)
>>> +             return ret;
>>> +
>>> +     return 0;
>>> +}
>>> +
>>> +static const struct of_device_id qcom_x1e_it8987_ec_of_match[] = {
>>> +     { .compatible = "lenovo,yoga-slim7x-ec" },
>>> +     { .compatible = "qcom,x1e-it9897-ec" },
>>> +     {}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, qcom_x1e_it8987_ec_of_match);
>>> +
>>> +static const struct i2c_device_id qcom_x1e_it8987_ec_i2c_id_table[] = {
>>> +     { "qcom-x1e-it8987-ec", },
>>> +     {}
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, qcom_x1e_it8987_ec_i2c_id_table);
>>> +
>>> +static DEFINE_SIMPLE_DEV_PM_OPS(qcom_x1e_it8987_ec_pm_ops,
>>> +             qcom_x1e_it8987_ec_suspend,
>>> +             qcom_x1e_it8987_ec_resume);
>>> +
>>> +static struct i2c_driver qcom_x1e_it8987_ec_i2c_driver = {
>>> +     .driver = {
>>> +             .name = "yoga-slim7x-ec",
>>> +             .of_match_table = qcom_x1e_it8987_ec_of_match,
>>> +             .pm = &qcom_x1e_it8987_ec_pm_ops
>>> +     },
>>> +     .probe = qcom_x1e_it8987_ec_probe,
>>> +     .remove = qcom_x1e_it8987_ec_remove,
>>> +     .id_table = qcom_x1e_it8987_ec_i2c_id_table,
>>> +};
>>> +module_i2c_driver(qcom_x1e_it8987_ec_i2c_driver);
>>> +
>>> +MODULE_DESCRIPTION("Lenovo Yoga Slim 7x Embedded Controller");
>>> +MODULE_LICENSE("GPL");
>>
>> Otherwise looks pretty good to me, nice hacking :)
>>
>> ---
>> bod
>>
Stephan Gerhold Dec. 20, 2024, 6:24 p.m. UTC | #2
On Fri, Dec 20, 2024 at 07:16:34PM +0100, Maya Matuszczyk wrote:
> Excuse the formatting, I've typed this reply from my phone
> 
> pt., 20 gru 2024, 19:05 użytkownik Stephan Gerhold <
> stephan.gerhold@linaro.org> napisał:
> 
> > On Thu, Dec 19, 2024 at 09:08:18PM +0100, Maya Matuszczyk wrote:
> > > This patch adds bindings for the EC firmware running on IT8987 present
> > > on most of X1E80100 devices
> > >
> > > Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
> > > ---
> > >  .../bindings/platform/qcom,x1e-it8987-ec.yaml | 52 +++++++++++++++++++
> > >  1 file changed, 52 insertions(+)
> > >  create mode 100644
> > Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> > >
> > > diff --git
> > a/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> > b/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> > > new file mode 100644
> > > index 000000000000..4a4f6eb63072
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> > > @@ -0,0 +1,52 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/platform/qcom,x1e-it8987-ec.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Qualcomm Embedded Controller on IT8987 chip.
> > > +
> > > +maintainers:
> > > +  - Maya Matuszczyk <maccraft123mc@gmail.com>
> > > +
> > > +description:
> > > +  Most x1e80100 laptops have an EC running on IT8987 MCU chip. The EC
> > controls
> > > +  minor functions, like fans, power LED, and on some laptops it also
> > handles
> > > +  keyboard hotkeys.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    oneOf:
> > > +      - const: qcom,x1e-it8987-ec
> >
> > Given that ECs tend to be somewhat device-specific and many vendors
> > might have slightly customized the EC firmware(?), I think it would be
> > better to disallow using this generic compatible without a more specific
> > one. In other words, I would drop this line and just keep the case
> > below:
> >
> I've looked at DSDT of other devices and they look to be compatible with
> what's on the devkit, with differences being extra features on magicbook
> art 14 and yoga slim 7x. Though this isn't a hill I'm willing to die on.
> 

I think it's fine to keep qcom,x1e-it8987-ec as second compatible.
However, without a more specific compatible, there is a risk we have
nothing to match on in case device-specific handling becomes necessary
in the driver at some point.

It's certainly subjective, but it might be better to play it safe here
and have a specific compatible that one can match, even if the behavior
is 99% the same. There will often be subtly different behavior across
devices, you mentioned the "keyboard backlight turning off and the power
LED slowly blinking", who knows what else exists.

I suppose worst case we could also use of_machine_is_compatible() to
just match the device the EC is running on, but I'm not sure if that
would be frowned upon.

Thanks,
Stephan
Dmitry Baryshkov Dec. 22, 2024, 6:56 a.m. UTC | #3
On Fri, Dec 20, 2024 at 07:50:45PM +0800, Aiqun(Maria) Yu wrote:
> On 12/20/2024 4:58 AM, Maya Matuszczyk wrote:
> > czw., 19 gru 2024 o 21:43 Bryan O'Donoghue
> > <bryan.odonoghue@linaro.org> napisał(a):
> >>
> >> On 19/12/2024 20:08, Maya Matuszczyk wrote:
> >>> Currently it features only reporting that the AP is going to suspend,
> >>> which results in keyboard backlight turning off and the power LED
> >>> slowly blinking on the Lenovo Yoga Slim 7x.
> >>>
> >>> Honor Magicbook Art 14 and Lenovo Yoga Slim 7x are known to have
> >>> firmware with extensions which would need appropriate handling.
> >>> For reverse engineering the firmware on them I have written a Rust
> >>> utility:
> >>>
> >>> https://github.com/Maccraft123/it8987-qcom-tool.git
> >>>
> >>> Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
> >>> ---
> >>>   MAINTAINERS                              |   6 +
> >>>   drivers/platform/arm64/Kconfig           |   8 ++
> >>>   drivers/platform/arm64/Makefile          |   1 +
> >>>   drivers/platform/arm64/qcom-x1e-it8987.c | 158 +++++++++++++++++++++++
> >>>   4 files changed, 173 insertions(+)
> >>>   create mode 100644 drivers/platform/arm64/qcom-x1e-it8987.c
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index b878ddc99f94..08d170e2e1e3 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -12890,6 +12890,12 @@ S:   Maintained
> >>>   W:  http://legousb.sourceforge.net/
> >>>   F:  drivers/usb/misc/legousbtower.c
> >>>
> >>> +QCOM IT8987 EC DRIVER
> >>> +M:   Maya Matuszczyk <maccraft123mc@gmail.com>
> >>> +S:   Maintained
> >>> +F:   Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> 
> Actually, the IT8987 is from ITE Tech. As far as I know, there are other
> platforms besides x1e that use this. So if this driver can be also
> applied for all ITE it8987, it might be better to say 'ITE IT8987'
> instead of 'QCOM IT8987'. This also applies to the file name and function.

ECS Liva QC710 also uses IT8987 as EC, though DSDT doesn't seem to
contain anything useful wrt. the EC.
Krzysztof Kozlowski Dec. 22, 2024, 2:34 p.m. UTC | #4
On 22/12/2024 08:55, Maya Matuszczyk wrote:
> niedz., 22 gru 2024 o 07:40 Krzysztof Kozlowski <krzk@kernel.org> napisał(a):
>>
>> On 22/12/2024 07:33, Krzysztof Kozlowski wrote:
>>>> +properties:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - const: qcom,x1e-it8987-ec
>>>
>>> That's not a SoC, so I don't understand:
>>> 1. referring to the SoC,
>>> 2. Having this alone and as fallback.
>>>
>>> It does not look like you tested the bindings, at least after quick
>>> look. Please run 'make dt_binding_check' (see
>>> Documentation/devicetree/bindings/writing-schema.rst for instructions).
>>> Maybe you need to update your dtschema and yamllint. Don't rely on
>>> distro packages for dtschema and be sure you are using the latest
>>> released dtschema.
>>
>> BTW, for sure Qualcomm did not develop/create it8987, so it cannot be
>> used here. Come with specific compatible for this given, one product:
>> embedded controller on one Lenovo laptop and use it also as filename.
> 
> Under these assumptions:
> 
> - Qualcomm developed the firmware running on the IT8987 in most x1e machines

No one here knows whether most x1e machines have this chip...

> - IT8987 is also used in other machines with a non-compatible firmware
> - The driver name should reflect the assumptions

I don't care about driver here, so you can use it for the driver but
these are not correct assumptions for the bindings.



> 
> I think the name qcom,x1e-it8987-ec is not the worst name for it, as
> "ite,it8987-ec" would imply compatibility with other devices running
> non-compatible firmware,
> and names specifying only the device wouldn't reflect the "firmware is
> based on what qcom did and it's driven the same way" part
> 
> Which other names do you think would fit this better?

I suggested the one in second reply:
lenovo,yoga-slim-whatever-model-it-is-ec

If you have any indication that Qualcomm firmware from a reference board
was used as a reference, it could be used as fallback, but I do not
believe you can have such indication considering downstream source code
does not exist and all other docs are confidential. Therefore lenovo EC
is the first implementation we see and we know anything about.


Best regards,
Krzysztof
Maya Matuszczyk Dec. 22, 2024, 3:07 p.m. UTC | #5
niedz., 22 gru 2024 o 15:40 Krzysztof Kozlowski <krzk@kernel.org> napisał(a):
>
> On 20/12/2024 19:24, Stephan Gerhold wrote:
> > On Fri, Dec 20, 2024 at 07:16:34PM +0100, Maya Matuszczyk wrote:
> >> Excuse the formatting, I've typed this reply from my phone
> >>
> >> pt., 20 gru 2024, 19:05 użytkownik Stephan Gerhold <
> >> stephan.gerhold@linaro.org> napisał:
> >>
> >>> On Thu, Dec 19, 2024 at 09:08:18PM +0100, Maya Matuszczyk wrote:
> >>>> This patch adds bindings for the EC firmware running on IT8987 present
> >>>> on most of X1E80100 devices
> >>>>
> >>>> Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
> >>>> ---
> >>>>  .../bindings/platform/qcom,x1e-it8987-ec.yaml | 52 +++++++++++++++++++
> >>>>  1 file changed, 52 insertions(+)
> >>>>  create mode 100644
> >>> Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> >>>>
> >>>> diff --git
> >>> a/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> >>> b/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..4a4f6eb63072
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
> >>>> @@ -0,0 +1,52 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>> +%YAML 1.2
> >>>> +---
> >>>> +$id: http://devicetree.org/schemas/platform/qcom,x1e-it8987-ec.yaml#
> >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>> +
> >>>> +title: Qualcomm Embedded Controller on IT8987 chip.
> >>>> +
> >>>> +maintainers:
> >>>> +  - Maya Matuszczyk <maccraft123mc@gmail.com>
> >>>> +
> >>>> +description:
> >>>> +  Most x1e80100 laptops have an EC running on IT8987 MCU chip. The EC
> >>> controls
> >>>> +  minor functions, like fans, power LED, and on some laptops it also
> >>> handles
> >>>> +  keyboard hotkeys.
> >>>> +
> >>>> +properties:
> >>>> +  compatible:
> >>>> +    oneOf:
> >>>> +      - const: qcom,x1e-it8987-ec
> >>>
> >>> Given that ECs tend to be somewhat device-specific and many vendors
> >>> might have slightly customized the EC firmware(?), I think it would be
> >>> better to disallow using this generic compatible without a more specific
> >>> one. In other words, I would drop this line and just keep the case
> >>> below:
> >>>
> >> I've looked at DSDT of other devices and they look to be compatible with
> >> what's on the devkit, with differences being extra features on magicbook
> >> art 14 and yoga slim 7x. Though this isn't a hill I'm willing to die on.
> >>
> >
> > I think it's fine to keep qcom,x1e-it8987-ec as second compatible.
>
>
> No, because:
> 1. There is no such thing as x1e
> 2. If there was a soc like this, this has nothing to do with SoC. It is
> not a component inside SoC and that is the only allowed case when you
> use SoC compatibles.

It was the closest thing I had for a "platform name"

>
> > However, without a more specific compatible, there is a risk we have
> > nothing to match on in case device-specific handling becomes necessary
> > in the driver at some point.
> >
> > It's certainly subjective, but it might be better to play it safe here
> > and have a specific compatible that one can match, even if the behavior
> > is 99% the same. There will often be subtly different behavior across
> > devices, you mentioned the "keyboard backlight turning off and the power
> > LED slowly blinking", who knows what else exists.
> >
> > I suppose worst case we could also use of_machine_is_compatible() to
> > just match the device the EC is running on, but I'm not sure if that
> > would be frowned upon.
>
>
> Unless you have some sort of insights or secret knowledge from Qualcomm
> (Bjorn or Konrad can chime in here), I think these are pure guesses that
> this is a Qualcomm product (implied by vendor prefix) or some sort of
> re-usable generic firmware from Qualcomm present on multiple devices.

The x elite devkit also has the IT8987 EC chip, and when comparing the
firmware of it and Yoga Slim 7x's EC there are similarities when
running them through strings
On both of them at the beginning there are strings that look like
version identifiers:
Devkit:
UUBBK V:00.20.00$
BBK-V20$

Slim7x:
UUBBK V:00.21.00$
BBK-V21$

With similar ones at the end:
Devkit:
EC VER:00.29.00$
LsFv:00.29.00$
Qualcomm$
WoS 8c GenX$
ODM$
MB:A0$
BUILD DATE:
02/0//2/24$
TIME:
14:33:35$

Slim7x:
EC VER:00.60.00$
LsFv:00.20.00$
Qualcomm$
WoS 8c GenX$
ODM$
MB:A0$
BUILD DATE:
2024/07/25$
TIME:
09:58:00$



>
> If the FW across devices is the same, then fallbacks for these are fine
> with me.

As the devkit has EC firmware that is handled the same way in DSDT
tables of most of other x1e laptops with the same EC, and is a subset
of what's done on Lenovo Yoga Slim 7x and Honor Magicbook Art 14 I
think the devkit's compatible  + -ec would be a good pick.

This conversation is getting long and I feel like I've said everything
I wanted to say, I'll just do what you tell me to do about the
fallback and binding filename.

>
> Best regards,
> Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml b/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
new file mode 100644
index 000000000000..4a4f6eb63072
--- /dev/null
+++ b/Documentation/devicetree/bindings/platform/qcom,x1e-it8987-ec.yaml
@@ -0,0 +1,52 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/platform/qcom,x1e-it8987-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Embedded Controller on IT8987 chip.
+
+maintainers:
+  - Maya Matuszczyk <maccraft123mc@gmail.com>
+
+description:
+  Most x1e80100 laptops have an EC running on IT8987 MCU chip. The EC controls
+  minor functions, like fans, power LED, and on some laptops it also handles
+  keyboard hotkeys.
+
+properties:
+  compatible:
+    oneOf:
+      - const: qcom,x1e-it8987-ec
+      - items:
+        - const: lenovo,yoga-slim7x-ec
+        - const: qcom,x1e-it8987-ec
+
+  reg:
+    const: 0x76
+
+  interrupts:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        embedded-controller@76 {
+            compatible = "lenovo,yoga-slim7x-ec", "qcom,x1e-it8987-ec";
+            reg = <0x76>;
+
+            interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_HIGH>;
+        };
+    };
+...