drivers/acpi/ec.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
On the MSI Modern 14 C5M the ECDT table contains invalid data:
UID : 00000000
GPE Number : 00 /* Invalid, 03 would be correct */
Namepath : "" /* Invalid, "\_SB.PCI0.SBRG.EC" would
* be correct
*/
This slows down the EC access as the wrong GPE event is used for
communication. Additionally the ID string is invalid.
Ignore such faulty ECDT tables by verifying that the ID string has
a valid format.
Tested-by: glpnk@proton.me
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
---
drivers/acpi/ec.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 6f4203716b53..75c7db8b156a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -23,8 +23,10 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/list.h>
+#include <linux/printk.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/suspend.h>
#include <linux/acpi.h>
#include <linux/dmi.h>
@@ -2031,6 +2033,21 @@ void __init acpi_ec_ecdt_probe(void)
goto out;
}
+ if (!strstarts(ecdt_ptr->id, "\\")) {
+ /*
+ * The ECDT table on some MSI notebooks contains invalid data, together
+ * with an empty ID string ("").
+ *
+ * Section 5.2.15 of the ACPI specification requires the ID string to be
+ * 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.
+ */
+ pr_err(FW_BUG "Ignoring ECDT due to invalid ID string \"%s\"\n", ecdt_ptr->id);
+ goto out;
+ }
+
ec = acpi_ec_alloc();
if (!ec)
goto out;
--
2.39.5On Fri, May 30, 2025 at 1:53 AM Armin Wolf <W_Armin@gmx.de> wrote:
>
> On the MSI Modern 14 C5M the ECDT table contains invalid data:
>
> UID : 00000000
> GPE Number : 00 /* Invalid, 03 would be correct */
> Namepath : "" /* Invalid, "\_SB.PCI0.SBRG.EC" would
> * be correct
> */
>
> This slows down the EC access as the wrong GPE event is used for
> communication. Additionally the ID string is invalid.
>
> Ignore such faulty ECDT tables by verifying that the ID string has
> a valid format.
>
> Tested-by: glpnk@proton.me
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> ---
> drivers/acpi/ec.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 6f4203716b53..75c7db8b156a 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -23,8 +23,10 @@
> #include <linux/delay.h>
> #include <linux/interrupt.h>
> #include <linux/list.h>
> +#include <linux/printk.h>
> #include <linux/spinlock.h>
> #include <linux/slab.h>
> +#include <linux/string.h>
> #include <linux/suspend.h>
> #include <linux/acpi.h>
> #include <linux/dmi.h>
> @@ -2031,6 +2033,21 @@ void __init acpi_ec_ecdt_probe(void)
> goto out;
> }
>
> + if (!strstarts(ecdt_ptr->id, "\\")) {
> + /*
> + * The ECDT table on some MSI notebooks contains invalid data, together
> + * with an empty ID string ("").
> + *
> + * Section 5.2.15 of the ACPI specification requires the ID string to be
> + * 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.
> + */
> + pr_err(FW_BUG "Ignoring ECDT due to invalid ID string \"%s\"\n", ecdt_ptr->id);
> + goto out;
> + }
> +
> ec = acpi_ec_alloc();
> if (!ec)
> goto out;
> --
Applied as 6.16-rc material, thanks!
Hello folks! It looks like this change makes the touchpad stop being detected entirely on my ThinkBook 14 G7 IML[0]. The kernel log says: > ACPI: EC: [Firmware Bug]: Ignoring ECDT due to invalid ID string "_SB.PC00.LPCB.EC0" Which looks technically invalid, but also probably important? :) Reverting the change makes things work again. I'm going to try a firmware update and pray to whatever dark gods are responsible for Lenovo firmware that they fixed their ACPI tables, but that requires getting Windows on the machine, so it'll take a bit. [0]: https://psref.lenovo.com/Product/ThinkBook/ThinkBook_14_G7_IML (resend -glpnk because my mail server is a shit)
Am 28.07.25 um 11:57 schrieb Ilya K: > Hello folks! > > It looks like this change makes the touchpad stop being detected entirely on my ThinkBook 14 G7 IML[0]. > > The kernel log says: > ACPI: EC: [Firmware Bug]: Ignoring ECDT due to invalid ID string "_SB.PC00.LPCB.EC0" > Which looks technically invalid, but also probably important? :) > > Reverting the change makes things work again. I'm going to try a firmware update and pray to > whatever dark gods are responsible for Lenovo firmware that they fixed their ACPI tables, but > that requires getting Windows on the machine, so it'll take a bit. > > [0]: https://psref.lenovo.com/Product/ThinkBook/ThinkBook_14_G7_IML > > (resend -glpnk because my mail server is a shit) Oh no, that sounds horrible :( Can you share the output of "acpidump" once the system is running the latest firmware? If a BIOS update does not solve the issue then we could give the ID string check a more leeway so that only empty strings are considered invalid. P.S: You could try if the BIOS update tool also works using Windows PE (https://wiki.archlinux.org/title/Windows_PE). I used this method a couple of times on my notebook and it worked flawlessly. Thanks, Armin Wolf
On 2025-07-29 01:13, Armin Wolf wrote:
>
> Oh no, that sounds horrible 🙁
>
> Can you share the output of "acpidump" once the system is running the latest firmware? If a BIOS update
> does not solve the issue then we could give the ID string check a more leeway so that only empty strings
> are considered invalid.
>
The firmware update did not, in fact, change anything. Here's the entire ECDT:
[000h 0000 004h] Signature : "ECDT" [Embedded Controller Boot Resources Table]
[004h 0004 004h] Table Length : 00000069
[008h 0008 001h] Revision : 01
[009h 0009 001h] Checksum : 6E
[00Ah 0010 006h] Oem ID : "LENOVO"
[010h 0016 008h] Oem Table ID : "CB-01 "
[018h 0024 004h] Oem Revision : 00000001
[01Ch 0028 004h] Asl Compiler ID : "LENO"
[020h 0032 004h] Asl Compiler Revision : 00000001
[024h 0036 00Ch] Command/Status Register : [Generic Address Structure]
[024h 0036 001h] Space ID : 01 [SystemIO]
[025h 0037 001h] Bit Width : 08
[026h 0038 001h] Bit Offset : 00
[027h 0039 001h] Encoded Access Width : 00 [Undefined/Legacy]
[028h 0040 008h] Address : 0000000000000066
[030h 0048 00Ch] Data Register : [Generic Address Structure]
[030h 0048 001h] Space ID : 01 [SystemIO]
[031h 0049 001h] Bit Width : 08
[032h 0050 001h] Bit Offset : 00
[033h 0051 001h] Encoded Access Width : 00 [Undefined/Legacy]
[034h 0052 008h] Address : 0000000000000062
[03Ch 0060 004h] UID : 00000000
[040h 0064 001h] GPE Number : 6E
[041h 0065 012h] Namepath : "_SB.PC00.LPCB.EC0"
Raw Table Data: Length 105 (0x69)
0000: 45 43 44 54 69 00 00 00 01 6E 4C 45 4E 4F 56 4F // ECDTi....nLENOVO
0010: 43 42 2D 30 31 20 20 20 01 00 00 00 4C 45 4E 4F // CB-01 ....LENO
0020: 01 00 00 00 01 08 00 00 66 00 00 00 00 00 00 00 // ........f.......
0030: 01 08 00 00 62 00 00 00 00 00 00 00 00 00 00 00 // ....b...........
0040: 6E 5F 53 42 2E 50 43 30 30 2E 4C 50 43 42 2E 45 // n_SB.PC00.LPCB.E
0050: 43 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // C0..............
0060: 00 00 00 00 00 00 00 00 00 // .........
It is fully identical on both firmware versions I've seen.
Am 29.07.25 um 06:29 schrieb Ilya K: > > On 2025-07-29 01:13, Armin Wolf wrote: >> Oh no, that sounds horrible 🙁 >> >> Can you share the output of "acpidump" once the system is running the latest firmware? If a BIOS update >> does not solve the issue then we could give the ID string check a more leeway so that only empty strings >> are considered invalid. >> > The firmware update did not, in fact, change anything. Here's the entire ECDT: > > [000h 0000 004h] Signature : "ECDT" [Embedded Controller Boot Resources Table] > [004h 0004 004h] Table Length : 00000069 > [008h 0008 001h] Revision : 01 > [009h 0009 001h] Checksum : 6E > [00Ah 0010 006h] Oem ID : "LENOVO" > [010h 0016 008h] Oem Table ID : "CB-01 " > [018h 0024 004h] Oem Revision : 00000001 > [01Ch 0028 004h] Asl Compiler ID : "LENO" > [020h 0032 004h] Asl Compiler Revision : 00000001 > > > [024h 0036 00Ch] Command/Status Register : [Generic Address Structure] > [024h 0036 001h] Space ID : 01 [SystemIO] > [025h 0037 001h] Bit Width : 08 > [026h 0038 001h] Bit Offset : 00 > [027h 0039 001h] Encoded Access Width : 00 [Undefined/Legacy] > [028h 0040 008h] Address : 0000000000000066 > > [030h 0048 00Ch] Data Register : [Generic Address Structure] > [030h 0048 001h] Space ID : 01 [SystemIO] > [031h 0049 001h] Bit Width : 08 > [032h 0050 001h] Bit Offset : 00 > [033h 0051 001h] Encoded Access Width : 00 [Undefined/Legacy] > [034h 0052 008h] Address : 0000000000000062 > > [03Ch 0060 004h] UID : 00000000 > [040h 0064 001h] GPE Number : 6E > [041h 0065 012h] Namepath : "_SB.PC00.LPCB.EC0" > > Raw Table Data: Length 105 (0x69) > > 0000: 45 43 44 54 69 00 00 00 01 6E 4C 45 4E 4F 56 4F // ECDTi....nLENOVO > 0010: 43 42 2D 30 31 20 20 20 01 00 00 00 4C 45 4E 4F // CB-01 ....LENO > 0020: 01 00 00 00 01 08 00 00 66 00 00 00 00 00 00 00 // ........f....... > 0030: 01 08 00 00 62 00 00 00 00 00 00 00 00 00 00 00 // ....b........... > 0040: 6E 5F 53 42 2E 50 43 30 30 2E 4C 50 43 42 2E 45 // n_SB.PC00.LPCB.E > 0050: 43 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // C0.............. > 0060: 00 00 00 00 00 00 00 00 00 // ......... > > It is fully identical on both firmware versions I've seen. > Alright, seems that we have to give the ID string a bit more leeway. I will prepare a patch for this. Thanks, Armin Wolf
© 2016 - 2026 Red Hat, Inc.