Created attachment 304726 [details] patch that should fix the issue Hello, Since upgrading to v6.4.7, the keyboard on this laptop no longer works. This laptop has both AMD and Intel Version, I'm using the AMD version. I believe this is similar to the issue reported in the mailing list: https://lore.kernel.org/all/596b9c4a-fb83-a8ab-3a44-6052d83fa546@augustwikerfors.se/. Users have reported issue with the keyboard prior to 6.0. And there's a patch made by one of the users, I made some modification to the patch they created and the issue has been fixed after applying the patch and recompile. The specs for this laptop are listed below: Laptop model: Lenovo ThinkPad Neo 14 (AMD) BIOS: R21ET42W (1.16) (latest available on Lenovo website, website is in Chinese[2]) CPU: AMD Ryzen 7 6800H with Radeon Graphics Kernel config: [3] Distribution: Arch Linux I have attached my acpidump, dmidecode as well as the patch I applied. It is adding the model to quirks table, but the parameter is different from the Yoga 7 patch (shareable=0 in my case). [1] https://bbs.archlinux.org/viewtopic.php?pid=2045467#p2045467 [2] https://think.lenovo.com.cn/support/driver/driverdetail.aspx?DEditid=102400 [3] https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/blob/d4a56a1e994201b6c607199922aa22e4337b56c9/config
Created attachment 304727 [details] ACPI dump for this laptop
Created attachment 304728 [details] dmidecode for this laptop
Just as I was about to click submit on my own report... I'll just copy and paste it here then -------------------- Link to #217718 and coup of others, but given the situation of things, I thought it could be more appropriate if I file a report specifically for my machine model. Last year, I've successfully tested and published a diff on https://bbs.archlinux.org/viewtopic.php?pid=2045467#p2045467. However, in my more recent (hours ago) test, Lenovo has changed the `DMI_BOARD_NAME` value to `21EF0002CD`, so created a new diff based on kernel `6.4.8` and attached it as the last section of this comment. I've already confirmed that my modification fixed the keyboard and trackpoint situation. But I do hope that someone give it a closer look because the modification is a little different compare to the others, notably: 1. I have to add two items into `override_table`, one for `irq` 1 and one for 12, in order to make both the keyboard and trackpoint to work. Which is different compare to other items listed (they only added one for `irq` 1). I've confirmed that only add `irq` 1 don't fix my keyboard neither trackpoint. 2. In my case, I have to use `ACPI_EDGE_SENSITIVE` instead of `ACPI_LEVEL_SENSITIVE` for `triggering`. `ACPI_LEVEL_SENSITIVE` don't match my machine. Here is notable messages before I applied my patch (and they no longer appear after my patch): [ 0.284061] ACPI: IRQ 1 override to edge, high(!) [ 0.284069] ACPI: IRQ 12 override to edge, high(!) And here is some information produced by `dmidecode`: $ sudo dmidecode -t system # dmidecode 3.4 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. Handle 0x0014, DMI type 1, 27 bytes System Information Manufacturer: LENOVO Product Name: 21EF0002CD Version: ThinkPad neo 14 Serial Number: <reduced> UUID: <reduced> Wake-up Type: Power Switch SKU Number: LENOVO_MT_21EF_BU_Think_FM_ThinkPad neo 14 Family: ThinkPad neo 14 $ sudo dmidecode -t baseboard # dmidecode 3.4 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. Handle 0x0015, DMI type 2, 15 bytes Base Board Information Manufacturer: LENOVO Product Name: 21EF0002CD Version: ThinkPad Serial Number: <reduced> Asset Tag: Not Available Features: Board is a hosting board Board is replaceable Location In Chassis: Not Available Chassis Handle: 0x0016 Type: Motherboard Contained Object Handles: 0 -------------------- $ git diff -- drivers/acpi/resource.c diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 1dd8d5aeb..c2419b020 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -481,6 +481,17 @@ static const struct dmi_system_id lg_laptop[] = { { } }; +static const struct dmi_system_id thinkpad_laptop[] = { + { + .ident = "ThinkPad neo 14", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_BOARD_NAME, "21EF0002CD"), + }, + }, + { } +}; + struct irq_override_cmp { const struct dmi_system_id *system; unsigned char irq; @@ -494,6 +505,8 @@ static const struct irq_override_cmp override_table[] = { { medion_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, { asus_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, { lg_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + { thinkpad_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + { thinkpad_laptop, 12, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, }; static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity,
Hi Sicong Jiang, can you change this bug to Regression? Because it is. Thanks!
UPDATE: I noticed that on another report, user August Wikerfors suggested that is it can be risky to match a board name. Given the fact that Lenovo also changed the board name on this model (from `Mayan` to `21EF0002CD`), I think we better also match the product name instead too. So, I tested matching `DMI_PRODUCT_NAME` instead of `DMI_BOARD_NAME` since both sharing the same value, and it too worked. In summary, that's static const struct dmi_system_id thinkpad_laptop[] = { { .ident = "ThinkPad neo 14", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_NAME, "21EF0002CD"), }, }, { } }; and then static const struct irq_override_cmp override_table[] = { .....other laptops..... { thinkpad_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, { thinkpad_laptop, 12, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, };
Can you see if this works? diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 1dd8d5aebf678..b74d7d8cc8630 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -19,7 +19,7 @@ #include <linux/dmi.h> #ifdef CONFIG_X86 -#define valid_IRQ(i) (((i) != 0) && ((i) != 2)) +#define valid_IRQ(i) ((i) > 2) static inline bool acpi_iospace_resource_valid(struct resource *res) { /* On X86 IO space is limited to the [0 - 64K] IO port range */
Hi Mario, I've tested the modification provided in Comment 6 based on a fresh `6.4.8` kernel code, and it don't seems to work at my end. As I mentioned in my Comment 3, I need to skip both IRQ 1 and 12, and the patch in Comment 6 don't skip 12. As a result, I got following message in dmesg: [ 0.304322] ACPI: IRQ 12 override to edge, high(!) and both the keyboard and trackpoint don't respond to my action. If you want to look deeper, here is some more information related to IRQ 1 and 12 in my dmesg: [ 2.045349] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [ 2.050070] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.050073] serio: i8042 AUX port at 0x60,0x64 irq 12 so 12 was not a made up number. Also, "PNP0303:KBD,PNP0f13:MOU" don't seemed to be a super weird configuration however, there are many platforms out there been configured in this way. Hope it helped. ------------------ I also noticed that in the patch Sicong Jiang provided in Comment 0 (the Description comment), he's trying to match the "21EF" prefix instead of the complete string of "21EF0002CD". Not sure if that's OK... unless of course Sicong Jiang was from Lenovo, then in that case thank you and please consider help Mario to fix my amdgpu driver too :)
It worked on one of my machines, but not the other too. It will not be viable for this issue.
I'm feeling a strong Whack Em' All vibe all over this now. But maybe that's the nature of these things. Anyway, I also discovered that Sicong Jiang has submitted another patch that utilized "21EF" instead of "21EF0002CD" as identifier (https://lore.kernel.org/all/20230531090635.89565-1-kevin.jiangsc@gmail.com/). Maybe "21EF" should be used here too to keep things consistent. I guess he's doing it right all the way, just use his patch provided in Comment 0 and it should resolve this issue. Thanks guys :)
There’s another patch series being worked on to hopefully fix this without needing quirks for every affected model: https://lore.kernel.org/regressions/20230809085526.84913-1-hdegoede@redhat.com/T/
(In reply to August Wikerfors from comment #10) > There’s another patch series being worked on to hopefully fix this without > needing quirks for every affected model: > https://lore.kernel.org/regressions/20230809085526.84913-1-hdegoede@redhat. > com/T/ Thanks for mentioning this. I've applied the patch and regression caused by the revert commit has been fixed on my laptop.