drivers/acpi/ec.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
It turns out that the ECDT table inside the ThinkBook 14 G7 IML
contains a valid EC description but an invalid ID string
("_SB.PC00.LPCB.EC0"). Ignoring this ECDT based on the invalid
ID string prevents the kernel from detecting the built-in touchpad,
so relax the sanity check of the ID string and only reject ECDTs
with empty ID strings.
Compile-tested only.
Reported-by: Ilya K <me@0upti.me>
Fixes: 7a0d59f6a913 ("ACPI: EC: Ignore ECDT tables with an invalid ID string")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
---
drivers/acpi/ec.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 75c7db8b156a..7855bbf752b1 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -2033,7 +2033,7 @@ void __init acpi_ec_ecdt_probe(void)
goto out;
}
- if (!strstarts(ecdt_ptr->id, "\\")) {
+ if (!strlen(ecdt_ptr->id)) {
/*
* The ECDT table on some MSI notebooks contains invalid data, together
* with an empty ID string ("").
@@ -2042,9 +2042,13 @@ void __init acpi_ec_ecdt_probe(void)
* a "fully qualified reference to the (...) embedded controller device",
* so this string always has to start with a backslash.
*
- * By verifying this we can avoid such faulty ECDT tables in a safe way.
+ * However some ThinkBook machines have a ECDT table with a valid EC
+ * description but an invalid ID string ("_SB.PC00.LPCB.EC0").
+ *
+ * Because of this we only check if the ID string is empty in order to
+ * avoid the obvious cases.
*/
- pr_err(FW_BUG "Ignoring ECDT due to invalid ID string \"%s\"\n", ecdt_ptr->id);
+ pr_err(FW_BUG "Ignoring ECDT due to empty ID string\n");
goto out;
}
--
2.39.5
On 2025-07-29 09:20, Armin Wolf wrote:
> It turns out that the ECDT table inside the ThinkBook 14 G7 IML
> contains a valid EC description but an invalid ID string
> ("_SB.PC00.LPCB.EC0"). Ignoring this ECDT based on the invalid
> ID string prevents the kernel from detecting the built-in touchpad,
> so relax the sanity check of the ID string and only reject ECDTs
> with empty ID strings.
>
> Compile-tested only.
>
> Reported-by: Ilya K <me@0upti.me>
> Fixes: 7a0d59f6a913 ("ACPI: EC: Ignore ECDT tables with an invalid ID string")
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> ---
> drivers/acpi/ec.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
Thanks, this works!
Tested-by: Ilya K <me@0upti.me>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 75c7db8b156a..7855bbf752b1 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -2033,7 +2033,7 @@ void __init acpi_ec_ecdt_probe(void)
> goto out;
> }
>
> - if (!strstarts(ecdt_ptr->id, "\\")) {
> + if (!strlen(ecdt_ptr->id)) {
> /*
> * The ECDT table on some MSI notebooks contains invalid data, together
> * with an empty ID string ("").
> @@ -2042,9 +2042,13 @@ void __init acpi_ec_ecdt_probe(void)
> * a "fully qualified reference to the (...) embedded controller device",
> * so this string always has to start with a backslash.
> *
> - * By verifying this we can avoid such faulty ECDT tables in a safe way.
> + * However some ThinkBook machines have a ECDT table with a valid EC
> + * description but an invalid ID string ("_SB.PC00.LPCB.EC0").
> + *
> + * Because of this we only check if the ID string is empty in order to
> + * avoid the obvious cases.
> */
> - pr_err(FW_BUG "Ignoring ECDT due to invalid ID string \"%s\"\n", ecdt_ptr->id);
> + pr_err(FW_BUG "Ignoring ECDT due to empty ID string\n");
> goto out;
> }
>
Would it maybe make sense to also log a warning for the old case? Maybe a vendor will notice it and fix the firmware...
(yeah yeah fat chance)
On Tue, Jul 29, 2025 at 9:01 AM Ilya K <me@0upti.me> wrote:
>
> On 2025-07-29 09:20, Armin Wolf wrote:
> > It turns out that the ECDT table inside the ThinkBook 14 G7 IML
> > contains a valid EC description but an invalid ID string
> > ("_SB.PC00.LPCB.EC0"). Ignoring this ECDT based on the invalid
> > ID string prevents the kernel from detecting the built-in touchpad,
> > so relax the sanity check of the ID string and only reject ECDTs
> > with empty ID strings.
> >
> > Compile-tested only.
> >
> > Reported-by: Ilya K <me@0upti.me>
> > Fixes: 7a0d59f6a913 ("ACPI: EC: Ignore ECDT tables with an invalid ID string")
> > Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> > ---
> > drivers/acpi/ec.c | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
>
> Thanks, this works!
>
> Tested-by: Ilya K <me@0upti.me>
Applied as 6.17-rc material and sorry for the delay (I was offline).
Thanks!
On 2025-08-12 16:32, Rafael J. Wysocki wrote: > > Applied as 6.17-rc material and sorry for the delay (I was offline). > > Thanks! Thanks! Tagging stable@ so we're hopefully in time for 6.16.1.
On Tue, Aug 12, 2025 at 06:51:10PM +0300, Ilya K wrote:
> On 2025-08-12 16:32, Rafael J. Wysocki wrote:
> >
> > Applied as 6.17-rc material and sorry for the delay (I was offline).
> >
> > Thanks!
>
> Thanks!
>
> Tagging stable@ so we're hopefully in time for 6.16.1.
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
Am 12.08.25 um 18:40 schrieb Greg KH: > On Tue, Aug 12, 2025 at 06:51:10PM +0300, Ilya K wrote: >> On 2025-08-12 16:32, Rafael J. Wysocki wrote: >>> Applied as 6.17-rc material and sorry for the delay (I was offline). >>> >>> Thanks! >> Thanks! >> >> Tagging stable@ so we're hopefully in time for 6.16.1. > <formletter> > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. > > </formletter> Agree. AFAIK the Fixes: tag should be enough to ensure that this patch gets included in the affected stable kernels. Thanks, Armin Wolf
On Tue, Aug 12, 2025 at 06:54:39PM +0200, Armin Wolf wrote: > Am 12.08.25 um 18:40 schrieb Greg KH: > > > On Tue, Aug 12, 2025 at 06:51:10PM +0300, Ilya K wrote: > > > On 2025-08-12 16:32, Rafael J. Wysocki wrote: > > > > Applied as 6.17-rc material and sorry for the delay (I was offline). > > > > > > > > Thanks! > > > Thanks! > > > > > > Tagging stable@ so we're hopefully in time for 6.16.1. > > <formletter> > > > > This is not the correct way to submit patches for inclusion in the > > stable kernel tree. Please read: > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > for how to do this properly. > > > > </formletter> > > Agree. > > AFAIK the Fixes: tag should be enough to ensure that this patch gets included > in the affected stable kernels. Not at all! Please read the above link for the full details on how to do this (hint, Fixes: will not do it.) thanks, greg k-h
Am 12.08.25 um 19:10 schrieb Greg KH: > On Tue, Aug 12, 2025 at 06:54:39PM +0200, Armin Wolf wrote: >> Am 12.08.25 um 18:40 schrieb Greg KH: >> >>> On Tue, Aug 12, 2025 at 06:51:10PM +0300, Ilya K wrote: >>>> On 2025-08-12 16:32, Rafael J. Wysocki wrote: >>>>> Applied as 6.17-rc material and sorry for the delay (I was offline). >>>>> >>>>> Thanks! >>>> Thanks! >>>> >>>> Tagging stable@ so we're hopefully in time for 6.16.1. >>> <formletter> >>> >>> This is not the correct way to submit patches for inclusion in the >>> stable kernel tree. Please read: >>> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html >>> for how to do this properly. >>> >>> </formletter> >> Agree. >> >> AFAIK the Fixes: tag should be enough to ensure that this patch gets included >> in the affected stable kernels. > Not at all! > > Please read the above link for the full details on how to do this (hint, > Fixes: will not do it.) > > thanks, > > greg k-h Oops, seems that i missed something rather significant about the stable kernels. I will give keep that in mind when sending future patches. Thanks, Armin Wolf
On 2025-08-12 20:10, Greg KH wrote: > > Please read the above link for the full details on how to do this (hint, > Fixes: will not do it.) > I might be missing something, but doesn't that just tell you to CC stable@? Or do you have to specifically have the CC on the initial patch submission, not anywhere in the thread?
On Tue, Aug 12, 2025 at 08:56:55PM +0300, Ilya K wrote: > On 2025-08-12 20:10, Greg KH wrote: > > > > Please read the above link for the full details on how to do this (hint, > > Fixes: will not do it.) > > > > I might be missing something, but doesn't that just tell you to CC stable@? It must be in the patch itself, in the signed-off-by area.
On Tue, Aug 12, 2025 at 9:33 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Aug 12, 2025 at 08:56:55PM +0300, Ilya K wrote: > > On 2025-08-12 20:10, Greg KH wrote: > > > > > > Please read the above link for the full details on how to do this (hint, > > > Fixes: will not do it.) > > > > > > > I might be missing something, but doesn't that just tell you to CC stable@? > > It must be in the patch itself, in the signed-off-by area. Well, to be precise, it must be present in the mainline commit of that patch and whether or not it will be there is entirely up to the committer. So adding a Cc: stable tag to a patch is a hint, which usually is appreciated as long as it is accurate, but the committer may still decide to not include it in the commit.
On Tue, Aug 12, 2025 at 7:57 PM Ilya K <me@0upti.me> wrote: > > On 2025-08-12 20:10, Greg KH wrote: > > > > Please read the above link for the full details on how to do this (hint, > > Fixes: will not do it.) > > > > I might be missing something, but doesn't that just tell you to CC stable@? > Or do you have to specifically have the CC on the initial patch submission, not anywhere in the thread? A Cc: stable in a patch (or elsewhere in the thread following it) is just a hint for the maintainer anyway. But no worries, I've added Cc: stable to the commit.
Am 29.07.25 um 09:00 schrieb Ilya K:
> On 2025-07-29 09:20, Armin Wolf wrote:
>> It turns out that the ECDT table inside the ThinkBook 14 G7 IML
>> contains a valid EC description but an invalid ID string
>> ("_SB.PC00.LPCB.EC0"). Ignoring this ECDT based on the invalid
>> ID string prevents the kernel from detecting the built-in touchpad,
>> so relax the sanity check of the ID string and only reject ECDTs
>> with empty ID strings.
>>
>> Compile-tested only.
>>
>> Reported-by: Ilya K <me@0upti.me>
>> Fixes: 7a0d59f6a913 ("ACPI: EC: Ignore ECDT tables with an invalid ID string")
>> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
>> ---
>> drivers/acpi/ec.c | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
> Thanks, this works!
>
> Tested-by: Ilya K <me@0upti.me>
>
>> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> index 75c7db8b156a..7855bbf752b1 100644
>> --- a/drivers/acpi/ec.c
>> +++ b/drivers/acpi/ec.c
>> @@ -2033,7 +2033,7 @@ void __init acpi_ec_ecdt_probe(void)
>> goto out;
>> }
>>
>> - if (!strstarts(ecdt_ptr->id, "\\")) {
>> + if (!strlen(ecdt_ptr->id)) {
>> /*
>> * The ECDT table on some MSI notebooks contains invalid data, together
>> * with an empty ID string ("").
>> @@ -2042,9 +2042,13 @@ void __init acpi_ec_ecdt_probe(void)
>> * a "fully qualified reference to the (...) embedded controller device",
>> * so this string always has to start with a backslash.
>> *
>> - * By verifying this we can avoid such faulty ECDT tables in a safe way.
>> + * However some ThinkBook machines have a ECDT table with a valid EC
>> + * description but an invalid ID string ("_SB.PC00.LPCB.EC0").
>> + *
>> + * Because of this we only check if the ID string is empty in order to
>> + * avoid the obvious cases.
>> */
>> - pr_err(FW_BUG "Ignoring ECDT due to invalid ID string \"%s\"\n", ecdt_ptr->id);
>> + pr_err(FW_BUG "Ignoring ECDT due to empty ID string\n");
>> goto out;
>> }
>>
> Would it maybe make sense to also log a warning for the old case? Maybe a vendor will notice it and fix the firmware...
> (yeah yeah fat chance)
The Linux kernel is not a verification kit, so i am against keeping the old check. Instead i suggest that we ensure that
the FWTS project (https://github.com/fwts/fwts) detects such invalid ECDT tables. Can you share the full output of
acpidump so that i can run the fwts tool on it?
Thanks,
Armin Wolf
> The Linux kernel is not a verification kit, so i am against keeping the old check. Instead i suggest that we ensure that > the FWTS project (https://github.com/fwts/fwts) detects such invalid ECDT tables. Can you share the full output of > acpidump so that i can run the fwts tool on it? > Uploaded here: https://github.com/K900/21mr-acpi-dumps Thanks!
Am 30.07.25 um 18:59 schrieb Ilya K: >> The Linux kernel is not a verification kit, so i am against keeping the old check. Instead i suggest that we ensure that >> the FWTS project (https://github.com/fwts/fwts) detects such invalid ECDT tables. Can you share the full output of >> acpidump so that i can run the fwts tool on it? >> > Uploaded here: https://github.com/K900/21mr-acpi-dumps > > Thanks! FWTS already warns that the ID string is wrong, so all good on this site. Thanks, Armin Wolf
> > FWTS already warns that the ID string is wrong, so all good on this site. > Is there anything else I can do to help get this merged? It's a pretty major regression and it would be good to have it in the next stable.
© 2016 - 2026 Red Hat, Inc.