* Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict
[not found] <CAAUQFRPW-rbcZV-=qV1NMjF_358sdJTiGvQuRxRqAsehY+J9Qg@mail.gmail.com>
@ 2026-10-15 18:25 ` Andy Shevchenko
2026-10-15 18:31 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2026-10-15 18:25 UTC (permalink / raw)
To: Nikodem Sanecki, Abduvaliy Abdulazizov, Dmitry Torokhov,
Mario Limonciello
Cc: westeri, linux-gpio, linux-acpi, linux-kernel
+Cc: Dmitry (as it might be related to keyboard configuration), others for
the previously reported same IRQ on the same GPIO controller but for some
camera stuff.
On Thu, Oct 15, 2026 at 03:13:02PM +0100, Nikodem Sanecki wrote:
> Hello,
>
> I'm reporting a Caps Lock LED issue on my Lenovo ThinkPad L13 Gen 2 AMD
> running Arch Linux. I found a workaround that completely fixes it, and I
> hope the findings might help implement a permanent kernel fix.
>
> *A quick note:* This is my first time using Linux, and I'm a complete
> beginner when it comes to kernel development. I used ChatGPT (GPT-6) to
> guide the troubleshooting process, analyse my laptop's ACPI firmware, and
> interpret the results. I personally ran the diagnostic commands and
> verified the observed behaviour, but the technical explanation below is
> AI-assisted. Please correct me if any of the analysis is inaccurate.
> Problem
>
> Under Linux, the physical Caps Lock indicator LED never illuminates, even
> though the Caps Lock key itself works normally.
>
> The LED works correctly under Windows and during certain stages of boot, so
> the hardware itself is functional.
>
> After investigating, GPT-6 identified what appears to be a conflict
> involving GPIO 11 on the AMD AMDI0030 controller.
>
> Booting Arch Linux with this kernel parameter completely fixes the problem:
>
> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
>
> The Caps Lock LED now works normally, and I haven't noticed any other
> hardware issues.
> System information
>
> -
>
> Device: Lenovo ThinkPad L13 Gen 2 AMD
> -
>
> DMI product name: 21AB004LSP
> -
>
> DMI product version/family: ThinkPad L13 Gen 2a
> -
>
> DMI vendor: LENOVO
> -
>
> DMI product SKU: LENOVO_MT_21AB_BU_Think_FM_ThinkPad L13 Gen 2a
> -
>
> Kernel: 7.2.9-arch1-1
> -
>
> Distribution: Arch Linux
> -
>
> BIOS: R1QET54W (1.40)
> -
>
> BIOS date: 2026-04-14
> -
>
> DSDT OEM ID: LENOVO
> -
>
> DSDT OEM Table ID: TP-R1Q
>
> Diagnostic findings
>
> The following is GPT-6's analysis of the diagnostic output and decompiled
> ACPI tables.
>
> *1. Linux sends the correct keyboard LED commands*
>
> Using bpftrace, we observed that atkbd_set_leds() consistently returned 0.
>
> Tracing ps2_command() for command 0x10ED produced:
>
> SETLEDS: value=4, caps=1
> SETLEDS: value=0, caps=0
> SETLEDS: value=4, caps=1
> SETLEDS: value=0, caps=0
>
> The driver reports success and sends the expected Caps Lock states, but the
> physical indicator stays off.
>
> *2. The embedded controller tracks Caps Lock correctly*
>
> The DSDT defines the CPLS field at EC offset 0x0F, bit 7.
>
> Reading that byte through the read-only ec_sys interface showed it changing
> from 0x00 to 0x80 when Caps Lock was toggled.
>
> Enabling dynamic debugging in drivers/acpi/ec.c confirmed that each Caps
> Lock press triggered EC query 0x78, which was scheduled, started and
> stopped successfully.
>
> *3. Lenovo's firmware controls GPIO 11*
>
> The DSDT contains:
>
> Method (_Q78, 0, NotSerialized)
> {
> If (CPLS)
> {
> WFIO (0x0B, 0x00)
> }
> Else
> {
> WFIO (0x0B, 0x01)
> }
> }
>
> The WFIO method writes bit 22 using WMEM(), targeting address 0xFED81500 +
> (11 * 4) = 0xFED8152C.
>
> This appears to control the Caps Lock indicator using GPIO 11.
>
> *4. The same GPIO is declared as an ACPI interrupt*
>
> In SSDT12, _SB.GPIO._AEI declares GPIO 11 as an edge-triggered, active-low,
> exclusive wake interrupt.
>
> Its _EVT handler includes:
>
> Case (0x0B)
> {
> MSTP (0x3911)
> Notify (\_SB.PCI0.GPP1, 0x00) // Bus Check
> }
>
> This appears to conflict with the firmware's use of GPIO 11 as an output.
>
> *5. GPIO registers confirm the suspected conflict*
>
> Without the workaround, /sys/kernel/debug/gpio showed:
>
> #11 ... input ... 0x457a00
> #11 ... input ... 0x057a00
>
> Pressing Caps Lock changed bit 22, but bit 23 (output enable) remained
> cleared.
>
> After booting with:
>
> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
>
> The result was:
>
> #11 ... output ... 0xc50000
>
> The output-enable bit was now set, and the physical Caps Lock LED worked
> flawlessly.
>
> The system was already using atkbd.reset=1 for a separate
> keyboard-backlight problem. That parameter alone had not fixed the Caps
> Lock LED.
> Possible explanation
>
> GPT-6's interpretation is that Linux's ACPI GPIO handling configures GPIO
> 11 as an interrupt input because of the firmware's _AEI declaration.
>
> That disables the output driver, even though the firmware continues
> updating the GPIO output-value bit when Caps Lock changes.
>
> Ignoring the interrupt allows the pin to remain configured as an output,
> restoring the indicator.
> Related upstream fix
>
> This seems very similar to the Acer Nitro V 16S AI issue addressed by:
>
> 6da1f3437435c82eaa15b121022474bb358ffe20
>
> "gpiolib: acpi: Ignore GPIO 11 interrupt on Acer Nitro V 16S AI"
>
> https://lists.openwall.net/linux-kernel/2026/10/02/1029
>
> However, there is an important difference.
>
> On my ThinkPad, the GPIO 11 _EVT handler issues a PCIe bus-check
> notification. I therefore don't know whether permanently ignoring the
> interrupt could interfere with PCIe-related events, hot-plugging or wake
> behaviour.
>
> So far, normal use with the workaround appears unaffected, but I haven't
> exhaustively tested those scenarios.
> Question
>
> Would a DMI-specific gpiolib ACPI quirk be appropriate for this ThinkPad,
> or should the conflicting GPIO declaration be handled differently because
> of the PCIe notification?
>
> I can provide the relevant decompiled DSDT/SSDT excerpts, additional
> diagnostic logs, or test a proposed fix if that would help.
>
> Thanks very much for your time, and apologies if I've misunderstood any of
> the technical details. I'm happy to run further tests with guidance.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict
2026-10-15 18:25 ` ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict Andy Shevchenko
@ 2026-10-15 18:31 ` Andy Shevchenko
2026-10-15 18:48 ` Mario Limonciello
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2026-10-15 18:31 UTC (permalink / raw)
To: Nikodem Sanecki, Abduvaliy Abdulazizov, Dmitry Torokhov,
Mario Limonciello
Cc: westeri, linux-gpio, linux-acpi, linux-kernel
On Thu, Oct 15, 2026 at 09:25:10PM +0300, Andy Shevchenko wrote:
> +Cc: Dmitry (as it might be related to keyboard configuration), others for
> the previously reported same IRQ on the same GPIO controller but for some
> camera stuff.
>
> On Thu, Oct 15, 2026 at 03:13:02PM +0100, Nikodem Sanecki wrote:
> > Hello,
> >
> > I'm reporting a Caps Lock LED issue on my Lenovo ThinkPad L13 Gen 2 AMD
> > running Arch Linux. I found a workaround that completely fixes it, and I
> > hope the findings might help implement a permanent kernel fix.
> >
> > *A quick note:* This is my first time using Linux, and I'm a complete
> > beginner when it comes to kernel development. I used ChatGPT (GPT-6) to
> > guide the troubleshooting process, analyse my laptop's ACPI firmware, and
> > interpret the results. I personally ran the diagnostic commands and
> > verified the observed behaviour, but the technical explanation below is
> > AI-assisted. Please correct me if any of the analysis is inaccurate.
> > Problem
> >
> > Under Linux, the physical Caps Lock indicator LED never illuminates, even
> > though the Caps Lock key itself works normally.
> >
> > The LED works correctly under Windows and during certain stages of boot, so
> > the hardware itself is functional.
> >
> > After investigating, GPT-6 identified what appears to be a conflict
> > involving GPIO 11 on the AMD AMDI0030 controller.
> >
> > Booting Arch Linux with this kernel parameter completely fixes the problem:
> >
> > gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
> >
> > The Caps Lock LED now works normally, and I haven't noticed any other
> > hardware issues.
> > System information
> >
> > -
> >
> > Device: Lenovo ThinkPad L13 Gen 2 AMD
> > -
> >
> > DMI product name: 21AB004LSP
> > -
> >
> > DMI product version/family: ThinkPad L13 Gen 2a
> > -
> >
> > DMI vendor: LENOVO
> > -
> >
> > DMI product SKU: LENOVO_MT_21AB_BU_Think_FM_ThinkPad L13 Gen 2a
> > -
> >
> > Kernel: 7.2.9-arch1-1
> > -
> >
> > Distribution: Arch Linux
> > -
> >
> > BIOS: R1QET54W (1.40)
> > -
> >
> > BIOS date: 2026-04-14
> > -
> >
> > DSDT OEM ID: LENOVO
> > -
> >
> > DSDT OEM Table ID: TP-R1Q
> >
> > Diagnostic findings
> >
> > The following is GPT-6's analysis of the diagnostic output and decompiled
> > ACPI tables.
> >
> > *1. Linux sends the correct keyboard LED commands*
> >
> > Using bpftrace, we observed that atkbd_set_leds() consistently returned 0.
> >
> > Tracing ps2_command() for command 0x10ED produced:
> >
> > SETLEDS: value=4, caps=1
> > SETLEDS: value=0, caps=0
> > SETLEDS: value=4, caps=1
> > SETLEDS: value=0, caps=0
> >
> > The driver reports success and sends the expected Caps Lock states, but the
> > physical indicator stays off.
> >
> > *2. The embedded controller tracks Caps Lock correctly*
> >
> > The DSDT defines the CPLS field at EC offset 0x0F, bit 7.
> >
> > Reading that byte through the read-only ec_sys interface showed it changing
> > from 0x00 to 0x80 when Caps Lock was toggled.
> >
> > Enabling dynamic debugging in drivers/acpi/ec.c confirmed that each Caps
> > Lock press triggered EC query 0x78, which was scheduled, started and
> > stopped successfully.
> >
> > *3. Lenovo's firmware controls GPIO 11*
> >
> > The DSDT contains:
> >
> > Method (_Q78, 0, NotSerialized)
> > {
> > If (CPLS)
> > {
> > WFIO (0x0B, 0x00)
> > }
> > Else
> > {
> > WFIO (0x0B, 0x01)
> > }
> > }
> >
> > The WFIO method writes bit 22 using WMEM(), targeting address 0xFED81500 +
> > (11 * 4) = 0xFED8152C.
> >
> > This appears to control the Caps Lock indicator using GPIO 11.
> >
> > *4. The same GPIO is declared as an ACPI interrupt*
> >
> > In SSDT12, _SB.GPIO._AEI declares GPIO 11 as an edge-triggered, active-low,
> > exclusive wake interrupt.
> >
> > Its _EVT handler includes:
> >
> > Case (0x0B)
> > {
> > MSTP (0x3911)
> > Notify (\_SB.PCI0.GPP1, 0x00) // Bus Check
This looks like some GPIO related notification. I dunno what Windows driver does.
Mario?
> > }
> >
> > This appears to conflict with the firmware's use of GPIO 11 as an output.
> >
> > *5. GPIO registers confirm the suspected conflict*
> >
> > Without the workaround, /sys/kernel/debug/gpio showed:
> >
> > #11 ... input ... 0x457a00
> > #11 ... input ... 0x057a00
> >
> > Pressing Caps Lock changed bit 22, but bit 23 (output enable) remained
> > cleared.
> >
> > After booting with:
> >
> > gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
> >
> > The result was:
> >
> > #11 ... output ... 0xc50000
> >
> > The output-enable bit was now set, and the physical Caps Lock LED worked
> > flawlessly.
> >
> > The system was already using atkbd.reset=1 for a separate
> > keyboard-backlight problem. That parameter alone had not fixed the Caps
> > Lock LED.
> > Possible explanation
> >
> > GPT-6's interpretation is that Linux's ACPI GPIO handling configures GPIO
> > 11 as an interrupt input because of the firmware's _AEI declaration.
> >
> > That disables the output driver, even though the firmware continues
> > updating the GPIO output-value bit when Caps Lock changes.
> >
> > Ignoring the interrupt allows the pin to remain configured as an output,
> > restoring the indicator.
> > Related upstream fix
> >
> > This seems very similar to the Acer Nitro V 16S AI issue addressed by:
> >
> > 6da1f3437435c82eaa15b121022474bb358ffe20
> >
> > "gpiolib: acpi: Ignore GPIO 11 interrupt on Acer Nitro V 16S AI"
> >
> > https://lists.openwall.net/linux-kernel/2026/10/02/1029
> >
> > However, there is an important difference.
> >
> > On my ThinkPad, the GPIO 11 _EVT handler issues a PCIe bus-check
> > notification. I therefore don't know whether permanently ignoring the
> > interrupt could interfere with PCIe-related events, hot-plugging or wake
> > behaviour.
> >
> > So far, normal use with the workaround appears unaffected, but I haven't
> > exhaustively tested those scenarios.
> > Question
> >
> > Would a DMI-specific gpiolib ACPI quirk be appropriate for this ThinkPad,
> > or should the conflicting GPIO declaration be handled differently because
> > of the PCIe notification?
> >
> > I can provide the relevant decompiled DSDT/SSDT excerpts, additional
> > diagnostic logs, or test a proposed fix if that would help.
Please do via some kind of file sharing service and reply with an URL to that.
> > Thanks very much for your time, and apologies if I've misunderstood any of
> > the technical details. I'm happy to run further tests with guidance.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict
2026-10-15 18:31 ` Andy Shevchenko
@ 2026-10-15 18:48 ` Mario Limonciello
2026-10-15 19:24 ` Mark Pearson
0 siblings, 1 reply; 6+ messages in thread
From: Mario Limonciello @ 2026-10-15 18:48 UTC (permalink / raw)
To: Andy Shevchenko, Nikodem Sanecki, Abduvaliy Abdulazizov,
Dmitry Torokhov, Mark Pearson
Cc: westeri, linux-gpio, linux-acpi, linux-kernel
On 10/15/26 13:31, Andy Shevchenko wrote:
> On Thu, Oct 15, 2026 at 09:25:10PM +0300, Andy Shevchenko wrote:
>> +Cc: Dmitry (as it might be related to keyboard configuration), others for
>> the previously reported same IRQ on the same GPIO controller but for some
>> camera stuff.
>>
>> On Thu, Oct 15, 2026 at 03:13:02PM +0100, Nikodem Sanecki wrote:
>>> Hello,
>>>
>>> I'm reporting a Caps Lock LED issue on my Lenovo ThinkPad L13 Gen 2 AMD
>>> running Arch Linux. I found a workaround that completely fixes it, and I
>>> hope the findings might help implement a permanent kernel fix.
>>>
>>> *A quick note:* This is my first time using Linux, and I'm a complete
>>> beginner when it comes to kernel development. I used ChatGPT (GPT-6) to
>>> guide the troubleshooting process, analyse my laptop's ACPI firmware, and
>>> interpret the results. I personally ran the diagnostic commands and
>>> verified the observed behaviour, but the technical explanation below is
>>> AI-assisted. Please correct me if any of the analysis is inaccurate.
>>> Problem
>>>
>>> Under Linux, the physical Caps Lock indicator LED never illuminates, even
>>> though the Caps Lock key itself works normally.
>>>
>>> The LED works correctly under Windows and during certain stages of boot, so
>>> the hardware itself is functional.
>>>
>>> After investigating, GPT-6 identified what appears to be a conflict
>>> involving GPIO 11 on the AMD AMDI0030 controller.
>>>
>>> Booting Arch Linux with this kernel parameter completely fixes the problem:
>>>
>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
>>>
>>> The Caps Lock LED now works normally, and I haven't noticed any other
>>> hardware issues.
>>> System information
>>>
>>> -
>>>
>>> Device: Lenovo ThinkPad L13 Gen 2 AMD
>>> -
>>>
>>> DMI product name: 21AB004LSP
>>> -
>>>
>>> DMI product version/family: ThinkPad L13 Gen 2a
>>> -
>>>
>>> DMI vendor: LENOVO
>>> -
>>>
>>> DMI product SKU: LENOVO_MT_21AB_BU_Think_FM_ThinkPad L13 Gen 2a
>>> -
>>>
>>> Kernel: 7.2.9-arch1-1
>>> -
>>>
>>> Distribution: Arch Linux
>>> -
>>>
>>> BIOS: R1QET54W (1.40)
>>> -
>>>
>>> BIOS date: 2026-04-14
>>> -
>>>
>>> DSDT OEM ID: LENOVO
>>> -
>>>
>>> DSDT OEM Table ID: TP-R1Q
>>>
>>> Diagnostic findings
>>>
>>> The following is GPT-6's analysis of the diagnostic output and decompiled
>>> ACPI tables.
>>>
>>> *1. Linux sends the correct keyboard LED commands*
>>>
>>> Using bpftrace, we observed that atkbd_set_leds() consistently returned 0.
>>>
>>> Tracing ps2_command() for command 0x10ED produced:
>>>
>>> SETLEDS: value=4, caps=1
>>> SETLEDS: value=0, caps=0
>>> SETLEDS: value=4, caps=1
>>> SETLEDS: value=0, caps=0
>>>
>>> The driver reports success and sends the expected Caps Lock states, but the
>>> physical indicator stays off.
>>>
>>> *2. The embedded controller tracks Caps Lock correctly*
>>>
>>> The DSDT defines the CPLS field at EC offset 0x0F, bit 7.
>>>
>>> Reading that byte through the read-only ec_sys interface showed it changing
>>> from 0x00 to 0x80 when Caps Lock was toggled.
>>>
>>> Enabling dynamic debugging in drivers/acpi/ec.c confirmed that each Caps
>>> Lock press triggered EC query 0x78, which was scheduled, started and
>>> stopped successfully.
>>>
>>> *3. Lenovo's firmware controls GPIO 11*
>>>
>>> The DSDT contains:
>>>
>>> Method (_Q78, 0, NotSerialized)
>>> {
>>> If (CPLS)
>>> {
>>> WFIO (0x0B, 0x00)
>>> }
>>> Else
>>> {
>>> WFIO (0x0B, 0x01)
>>> }
>>> }
>>>
>>> The WFIO method writes bit 22 using WMEM(), targeting address 0xFED81500 +
>>> (11 * 4) = 0xFED8152C.
>>>
>>> This appears to control the Caps Lock indicator using GPIO 11.
>>>
>>> *4. The same GPIO is declared as an ACPI interrupt*
>>>
>>> In SSDT12, _SB.GPIO._AEI declares GPIO 11 as an edge-triggered, active-low,
>>> exclusive wake interrupt.
>>>
>>> Its _EVT handler includes:
>>>
>>> Case (0x0B)
>>> {
>>> MSTP (0x3911)
>>> Notify (\_SB.PCI0.GPP1, 0x00) // Bus Check
>
> This looks like some GPIO related notification. I dunno what Windows driver does.
> Mario?
>
Honestly - this sounds like a copy / paste BIOS bug that they copied the
SSDT from one system and didn't change it.
I would think quirking it makes sense if the BIOS isn't going to be fixed.
Before we go much further can you check if this is the latest BIOS?
Check Lenovo's website, in case it wasn't brought to LVFS.
Also; Mark can you ask BIOS guys to look this over?
It sure seems like GPIO 11 shouldn't be in _AEI.
>>> }
>>>
>>> This appears to conflict with the firmware's use of GPIO 11 as an output.
>>>
>>> *5. GPIO registers confirm the suspected conflict*
>>>
>>> Without the workaround, /sys/kernel/debug/gpio showed:
>>>
>>> #11 ... input ... 0x457a00
>>> #11 ... input ... 0x057a00
>>>
>>> Pressing Caps Lock changed bit 22, but bit 23 (output enable) remained
>>> cleared.
>>>
>>> After booting with:
>>>
>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
>>>
>>> The result was:
>>>
>>> #11 ... output ... 0xc50000
>>>
>>> The output-enable bit was now set, and the physical Caps Lock LED worked
>>> flawlessly.
>>>
>>> The system was already using atkbd.reset=1 for a separate
>>> keyboard-backlight problem. That parameter alone had not fixed the Caps
>>> Lock LED.
>>> Possible explanation
>>>
>>> GPT-6's interpretation is that Linux's ACPI GPIO handling configures GPIO
>>> 11 as an interrupt input because of the firmware's _AEI declaration.
>>>
>>> That disables the output driver, even though the firmware continues
>>> updating the GPIO output-value bit when Caps Lock changes.
>>>
>>> Ignoring the interrupt allows the pin to remain configured as an output,
>>> restoring the indicator.
>>> Related upstream fix
>>>
>>> This seems very similar to the Acer Nitro V 16S AI issue addressed by:
>>>
>>> 6da1f3437435c82eaa15b121022474bb358ffe20
>>>
>>> "gpiolib: acpi: Ignore GPIO 11 interrupt on Acer Nitro V 16S AI"
>>>
>>> https://lists.openwall.net/linux-kernel/2026/10/02/1029
>>>
>>> However, there is an important difference.
>>>
>>> On my ThinkPad, the GPIO 11 _EVT handler issues a PCIe bus-check
>>> notification. I therefore don't know whether permanently ignoring the
>>> interrupt could interfere with PCIe-related events, hot-plugging or wake
>>> behaviour.
>>>
>>> So far, normal use with the workaround appears unaffected, but I haven't
>>> exhaustively tested those scenarios.
>>> Question
>>>
>>> Would a DMI-specific gpiolib ACPI quirk be appropriate for this ThinkPad,
>>> or should the conflicting GPIO declaration be handled differently because
>>> of the PCIe notification?
>>>
>>> I can provide the relevant decompiled DSDT/SSDT excerpts, additional
>>> diagnostic logs, or test a proposed fix if that would help.
>
> Please do via some kind of file sharing service and reply with an URL to that.
I'll second this - put all the artifacts in a kernel bugzilla please.
From the current AI analysis I agree a quirk makes sense, but we can
double check everything.
>
>>> Thanks very much for your time, and apologies if I've misunderstood any of
>>> the technical details. I'm happy to run further tests with guidance.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict
2026-10-15 18:48 ` Mario Limonciello
@ 2026-10-15 19:24 ` Mark Pearson
2026-10-15 20:13 ` Nikodem Sanecki
0 siblings, 1 reply; 6+ messages in thread
From: Mark Pearson @ 2026-10-15 19:24 UTC (permalink / raw)
To: Limonciello, Mario, Andy Shevchenko, Nikodem Sanecki,
Abduvaliy Abdulazizov, Dmitry Torokhov
Cc: Mika Westerberg, linux-gpio, linux-acpi, linux-kernel
On Thu, Oct 15, 2026, at 2:48 PM, Mario Limonciello wrote:
> On 10/15/26 13:31, Andy Shevchenko wrote:
>> On Thu, Oct 15, 2026 at 09:25:10PM +0300, Andy Shevchenko wrote:
>>> +Cc: Dmitry (as it might be related to keyboard configuration), others for
>>> the previously reported same IRQ on the same GPIO controller but for some
>>> camera stuff.
>>>
>>> On Thu, Oct 15, 2026 at 03:13:02PM +0100, Nikodem Sanecki wrote:
>>>> Hello,
>>>>
>>>> I'm reporting a Caps Lock LED issue on my Lenovo ThinkPad L13 Gen 2 AMD
>>>> running Arch Linux. I found a workaround that completely fixes it, and I
>>>> hope the findings might help implement a permanent kernel fix.
>>>>
>>>> *A quick note:* This is my first time using Linux, and I'm a complete
>>>> beginner when it comes to kernel development. I used ChatGPT (GPT-6) to
>>>> guide the troubleshooting process, analyse my laptop's ACPI firmware, and
>>>> interpret the results. I personally ran the diagnostic commands and
>>>> verified the observed behaviour, but the technical explanation below is
>>>> AI-assisted. Please correct me if any of the analysis is inaccurate.
>>>> Problem
>>>>
>>>> Under Linux, the physical Caps Lock indicator LED never illuminates, even
>>>> though the Caps Lock key itself works normally.
>>>>
>>>> The LED works correctly under Windows and during certain stages of boot, so
>>>> the hardware itself is functional.
>>>>
>>>> After investigating, GPT-6 identified what appears to be a conflict
>>>> involving GPIO 11 on the AMD AMDI0030 controller.
>>>>
>>>> Booting Arch Linux with this kernel parameter completely fixes the problem:
>>>>
>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
>>>>
>>>> The Caps Lock LED now works normally, and I haven't noticed any other
>>>> hardware issues.
>>>> System information
>>>>
>>>> -
>>>>
>>>> Device: Lenovo ThinkPad L13 Gen 2 AMD
>>>> -
>>>>
>>>> DMI product name: 21AB004LSP
>>>> -
>>>>
>>>> DMI product version/family: ThinkPad L13 Gen 2a
>>>> -
>>>>
>>>> DMI vendor: LENOVO
>>>> -
>>>>
>>>> DMI product SKU: LENOVO_MT_21AB_BU_Think_FM_ThinkPad L13 Gen 2a
>>>> -
>>>>
>>>> Kernel: 7.2.9-arch1-1
>>>> -
>>>>
>>>> Distribution: Arch Linux
>>>> -
>>>>
>>>> BIOS: R1QET54W (1.40)
>>>> -
>>>>
>>>> BIOS date: 2026-04-14
>>>> -
>>>>
>>>> DSDT OEM ID: LENOVO
>>>> -
>>>>
>>>> DSDT OEM Table ID: TP-R1Q
>>>>
>>>> Diagnostic findings
>>>>
>>>> The following is GPT-6's analysis of the diagnostic output and decompiled
>>>> ACPI tables.
>>>>
>>>> *1. Linux sends the correct keyboard LED commands*
>>>>
>>>> Using bpftrace, we observed that atkbd_set_leds() consistently returned 0.
>>>>
>>>> Tracing ps2_command() for command 0x10ED produced:
>>>>
>>>> SETLEDS: value=4, caps=1
>>>> SETLEDS: value=0, caps=0
>>>> SETLEDS: value=4, caps=1
>>>> SETLEDS: value=0, caps=0
>>>>
>>>> The driver reports success and sends the expected Caps Lock states, but the
>>>> physical indicator stays off.
>>>>
>>>> *2. The embedded controller tracks Caps Lock correctly*
>>>>
>>>> The DSDT defines the CPLS field at EC offset 0x0F, bit 7.
>>>>
>>>> Reading that byte through the read-only ec_sys interface showed it changing
>>>> from 0x00 to 0x80 when Caps Lock was toggled.
>>>>
>>>> Enabling dynamic debugging in drivers/acpi/ec.c confirmed that each Caps
>>>> Lock press triggered EC query 0x78, which was scheduled, started and
>>>> stopped successfully.
>>>>
>>>> *3. Lenovo's firmware controls GPIO 11*
>>>>
>>>> The DSDT contains:
>>>>
>>>> Method (_Q78, 0, NotSerialized)
>>>> {
>>>> If (CPLS)
>>>> {
>>>> WFIO (0x0B, 0x00)
>>>> }
>>>> Else
>>>> {
>>>> WFIO (0x0B, 0x01)
>>>> }
>>>> }
>>>>
>>>> The WFIO method writes bit 22 using WMEM(), targeting address 0xFED81500 +
>>>> (11 * 4) = 0xFED8152C.
>>>>
>>>> This appears to control the Caps Lock indicator using GPIO 11.
>>>>
>>>> *4. The same GPIO is declared as an ACPI interrupt*
>>>>
>>>> In SSDT12, _SB.GPIO._AEI declares GPIO 11 as an edge-triggered, active-low,
>>>> exclusive wake interrupt.
>>>>
>>>> Its _EVT handler includes:
>>>>
>>>> Case (0x0B)
>>>> {
>>>> MSTP (0x3911)
>>>> Notify (\_SB.PCI0.GPP1, 0x00) // Bus Check
>>
>> This looks like some GPIO related notification. I dunno what Windows driver does.
>> Mario?
>>
>
> Honestly - this sounds like a copy / paste BIOS bug that they copied the
> SSDT from one system and didn't change it.
>
> I would think quirking it makes sense if the BIOS isn't going to be fixed.
>
> Before we go much further can you check if this is the latest BIOS?
> Check Lenovo's website, in case it wasn't brought to LVFS.
>
> Also; Mark can you ask BIOS guys to look this over?
>
> It sure seems like GPIO 11 shouldn't be in _AEI.
>
Yep - created internal ticket LO-4711
Just a note though - the platform was not in the Linux program (and is rather old) - so my expectations of getting a fix is rather low I'm afraid
I'd get the quirk ready, and if I don't get any feedback from the FW team by next week go ahead with that.
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict
2026-10-15 19:24 ` Mark Pearson
@ 2026-10-15 20:13 ` Nikodem Sanecki
2026-10-15 20:26 ` Mario Limonciello
0 siblings, 1 reply; 6+ messages in thread
From: Nikodem Sanecki @ 2026-10-15 20:13 UTC (permalink / raw)
To: Mark Pearson
Cc: Limonciello, Mario, Andy Shevchenko, Abduvaliy Abdulazizov,
Dmitry Torokhov, Mika Westerberg, linux-gpio, linux-acpi,
linux-kernel
Thank you for looking into this.
I've checked Lenovo's website. My installed BIOS is R1QET54W (1.40),
which matches the latest advertised version. The version history on
their website appears inconsistent, though.
I also have the sanitised ACPI excerpts and diagnostic logs ready.
Given that a patch has now been submitted, would a kernel Bugzilla
report with these artifacts still be useful?
Happy to help with any further testing.
Thanks,
Nikodem
On Thu, Oct 15, 2026 at 8:25 PM Mark Pearson <mpearson-lenovo@squebb.ca> wrote:
>
>
> On Thu, Oct 15, 2026, at 2:48 PM, Mario Limonciello wrote:
> > On 10/15/26 13:31, Andy Shevchenko wrote:
> >> On Thu, Oct 15, 2026 at 09:25:10PM +0300, Andy Shevchenko wrote:
> >>> +Cc: Dmitry (as it might be related to keyboard configuration), others for
> >>> the previously reported same IRQ on the same GPIO controller but for some
> >>> camera stuff.
> >>>
> >>> On Thu, Oct 15, 2026 at 03:13:02PM +0100, Nikodem Sanecki wrote:
> >>>> Hello,
> >>>>
> >>>> I'm reporting a Caps Lock LED issue on my Lenovo ThinkPad L13 Gen 2 AMD
> >>>> running Arch Linux. I found a workaround that completely fixes it, and I
> >>>> hope the findings might help implement a permanent kernel fix.
> >>>>
> >>>> *A quick note:* This is my first time using Linux, and I'm a complete
> >>>> beginner when it comes to kernel development. I used ChatGPT (GPT-6) to
> >>>> guide the troubleshooting process, analyse my laptop's ACPI firmware, and
> >>>> interpret the results. I personally ran the diagnostic commands and
> >>>> verified the observed behaviour, but the technical explanation below is
> >>>> AI-assisted. Please correct me if any of the analysis is inaccurate.
> >>>> Problem
> >>>>
> >>>> Under Linux, the physical Caps Lock indicator LED never illuminates, even
> >>>> though the Caps Lock key itself works normally.
> >>>>
> >>>> The LED works correctly under Windows and during certain stages of boot, so
> >>>> the hardware itself is functional.
> >>>>
> >>>> After investigating, GPT-6 identified what appears to be a conflict
> >>>> involving GPIO 11 on the AMD AMDI0030 controller.
> >>>>
> >>>> Booting Arch Linux with this kernel parameter completely fixes the problem:
> >>>>
> >>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
> >>>>
> >>>> The Caps Lock LED now works normally, and I haven't noticed any other
> >>>> hardware issues.
> >>>> System information
> >>>>
> >>>> -
> >>>>
> >>>> Device: Lenovo ThinkPad L13 Gen 2 AMD
> >>>> -
> >>>>
> >>>> DMI product name: 21AB004LSP
> >>>> -
> >>>>
> >>>> DMI product version/family: ThinkPad L13 Gen 2a
> >>>> -
> >>>>
> >>>> DMI vendor: LENOVO
> >>>> -
> >>>>
> >>>> DMI product SKU: LENOVO_MT_21AB_BU_Think_FM_ThinkPad L13 Gen 2a
> >>>> -
> >>>>
> >>>> Kernel: 7.2.9-arch1-1
> >>>> -
> >>>>
> >>>> Distribution: Arch Linux
> >>>> -
> >>>>
> >>>> BIOS: R1QET54W (1.40)
> >>>> -
> >>>>
> >>>> BIOS date: 2026-04-14
> >>>> -
> >>>>
> >>>> DSDT OEM ID: LENOVO
> >>>> -
> >>>>
> >>>> DSDT OEM Table ID: TP-R1Q
> >>>>
> >>>> Diagnostic findings
> >>>>
> >>>> The following is GPT-6's analysis of the diagnostic output and decompiled
> >>>> ACPI tables.
> >>>>
> >>>> *1. Linux sends the correct keyboard LED commands*
> >>>>
> >>>> Using bpftrace, we observed that atkbd_set_leds() consistently returned 0.
> >>>>
> >>>> Tracing ps2_command() for command 0x10ED produced:
> >>>>
> >>>> SETLEDS: value=4, caps=1
> >>>> SETLEDS: value=0, caps=0
> >>>> SETLEDS: value=4, caps=1
> >>>> SETLEDS: value=0, caps=0
> >>>>
> >>>> The driver reports success and sends the expected Caps Lock states, but the
> >>>> physical indicator stays off.
> >>>>
> >>>> *2. The embedded controller tracks Caps Lock correctly*
> >>>>
> >>>> The DSDT defines the CPLS field at EC offset 0x0F, bit 7.
> >>>>
> >>>> Reading that byte through the read-only ec_sys interface showed it changing
> >>>> from 0x00 to 0x80 when Caps Lock was toggled.
> >>>>
> >>>> Enabling dynamic debugging in drivers/acpi/ec.c confirmed that each Caps
> >>>> Lock press triggered EC query 0x78, which was scheduled, started and
> >>>> stopped successfully.
> >>>>
> >>>> *3. Lenovo's firmware controls GPIO 11*
> >>>>
> >>>> The DSDT contains:
> >>>>
> >>>> Method (_Q78, 0, NotSerialized)
> >>>> {
> >>>> If (CPLS)
> >>>> {
> >>>> WFIO (0x0B, 0x00)
> >>>> }
> >>>> Else
> >>>> {
> >>>> WFIO (0x0B, 0x01)
> >>>> }
> >>>> }
> >>>>
> >>>> The WFIO method writes bit 22 using WMEM(), targeting address 0xFED81500 +
> >>>> (11 * 4) = 0xFED8152C.
> >>>>
> >>>> This appears to control the Caps Lock indicator using GPIO 11.
> >>>>
> >>>> *4. The same GPIO is declared as an ACPI interrupt*
> >>>>
> >>>> In SSDT12, _SB.GPIO._AEI declares GPIO 11 as an edge-triggered, active-low,
> >>>> exclusive wake interrupt.
> >>>>
> >>>> Its _EVT handler includes:
> >>>>
> >>>> Case (0x0B)
> >>>> {
> >>>> MSTP (0x3911)
> >>>> Notify (\_SB.PCI0.GPP1, 0x00) // Bus Check
> >>
> >> This looks like some GPIO related notification. I dunno what Windows driver does.
> >> Mario?
> >>
> >
> > Honestly - this sounds like a copy / paste BIOS bug that they copied the
> > SSDT from one system and didn't change it.
> >
> > I would think quirking it makes sense if the BIOS isn't going to be fixed.
> >
> > Before we go much further can you check if this is the latest BIOS?
> > Check Lenovo's website, in case it wasn't brought to LVFS.
> >
> > Also; Mark can you ask BIOS guys to look this over?
> >
> > It sure seems like GPIO 11 shouldn't be in _AEI.
> >
> Yep - created internal ticket LO-4711
> Just a note though - the platform was not in the Linux program (and is rather old) - so my expectations of getting a fix is rather low I'm afraid
>
> I'd get the quirk ready, and if I don't get any feedback from the FW team by next week go ahead with that.
>
> Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict
2026-10-15 20:13 ` Nikodem Sanecki
@ 2026-10-15 20:26 ` Mario Limonciello
0 siblings, 0 replies; 6+ messages in thread
From: Mario Limonciello @ 2026-10-15 20:26 UTC (permalink / raw)
To: Nikodem Sanecki, Mark Pearson
Cc: Andy Shevchenko, Abduvaliy Abdulazizov, Dmitry Torokhov,
Mika Westerberg, linux-gpio, linux-acpi, linux-kernel
On 10/15/26 15:13, Nikodem Sanecki wrote:
> Thank you for looking into this.
>
> I've checked Lenovo's website. My installed BIOS is R1QET54W (1.40),
> which matches the latest advertised version. The version history on
> their website appears inconsistent, though.
>
OK thanks.
> I also have the sanitised ACPI excerpts and diagnostic logs ready.
> Given that a patch has now been submitted, would a kernel Bugzilla
> report with these artifacts still be useful?
Yes; we should still have the artifacts somewhere. We can close the bug
completed but add a Link: to the patch.
>
> Happy to help with any further testing.
Can you please test the patch I CC'ed you on?
https://lore.kernel.org/linux-gpio/20261015193924.4081906-1-mario.limonciello@amd.com/
>
> Thanks,
> Nikodem
>
> On Thu, Oct 15, 2026 at 8:25 PM Mark Pearson <mpearson-lenovo@squebb.ca> wrote:
>>
>>
>> On Thu, Oct 15, 2026, at 2:48 PM, Mario Limonciello wrote:
>>> On 10/15/26 13:31, Andy Shevchenko wrote:
>>>> On Thu, Oct 15, 2026 at 09:25:10PM +0300, Andy Shevchenko wrote:
>>>>> +Cc: Dmitry (as it might be related to keyboard configuration), others for
>>>>> the previously reported same IRQ on the same GPIO controller but for some
>>>>> camera stuff.
>>>>>
>>>>> On Thu, Oct 15, 2026 at 03:13:02PM +0100, Nikodem Sanecki wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'm reporting a Caps Lock LED issue on my Lenovo ThinkPad L13 Gen 2 AMD
>>>>>> running Arch Linux. I found a workaround that completely fixes it, and I
>>>>>> hope the findings might help implement a permanent kernel fix.
>>>>>>
>>>>>> *A quick note:* This is my first time using Linux, and I'm a complete
>>>>>> beginner when it comes to kernel development. I used ChatGPT (GPT-6) to
>>>>>> guide the troubleshooting process, analyse my laptop's ACPI firmware, and
>>>>>> interpret the results. I personally ran the diagnostic commands and
>>>>>> verified the observed behaviour, but the technical explanation below is
>>>>>> AI-assisted. Please correct me if any of the analysis is inaccurate.
>>>>>> Problem
>>>>>>
>>>>>> Under Linux, the physical Caps Lock indicator LED never illuminates, even
>>>>>> though the Caps Lock key itself works normally.
>>>>>>
>>>>>> The LED works correctly under Windows and during certain stages of boot, so
>>>>>> the hardware itself is functional.
>>>>>>
>>>>>> After investigating, GPT-6 identified what appears to be a conflict
>>>>>> involving GPIO 11 on the AMD AMDI0030 controller.
>>>>>>
>>>>>> Booting Arch Linux with this kernel parameter completely fixes the problem:
>>>>>>
>>>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@11
>>>>>>
>>>>>> The Caps Lock LED now works normally, and I haven't noticed any other
>>>>>> hardware issues.
>>>>>> System information
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Device: Lenovo ThinkPad L13 Gen 2 AMD
>>>>>> -
>>>>>>
>>>>>> DMI product name: 21AB004LSP
>>>>>> -
>>>>>>
>>>>>> DMI product version/family: ThinkPad L13 Gen 2a
>>>>>> -
>>>>>>
>>>>>> DMI vendor: LENOVO
>>>>>> -
>>>>>>
>>>>>> DMI product SKU: LENOVO_MT_21AB_BU_Think_FM_ThinkPad L13 Gen 2a
>>>>>> -
>>>>>>
>>>>>> Kernel: 7.2.9-arch1-1
>>>>>> -
>>>>>>
>>>>>> Distribution: Arch Linux
>>>>>> -
>>>>>>
>>>>>> BIOS: R1QET54W (1.40)
>>>>>> -
>>>>>>
>>>>>> BIOS date: 2026-04-14
>>>>>> -
>>>>>>
>>>>>> DSDT OEM ID: LENOVO
>>>>>> -
>>>>>>
>>>>>> DSDT OEM Table ID: TP-R1Q
>>>>>>
>>>>>> Diagnostic findings
>>>>>>
>>>>>> The following is GPT-6's analysis of the diagnostic output and decompiled
>>>>>> ACPI tables.
>>>>>>
>>>>>> *1. Linux sends the correct keyboard LED commands*
>>>>>>
>>>>>> Using bpftrace, we observed that atkbd_set_leds() consistently returned 0.
>>>>>>
>>>>>> Tracing ps2_command() for command 0x10ED produced:
>>>>>>
>>>>>> SETLEDS: value=4, caps=1
>>>>>> SETLEDS: value=0, caps=0
>>>>>> SETLEDS: value=4, caps=1
>>>>>> SETLEDS: value=0, caps=0
>>>>>>
>>>>>> The driver reports success and sends the expected Caps Lock states, but the
>>>>>> physical indicator stays off.
>>>>>>
>>>>>> *2. The embedded controller tracks Caps Lock correctly*
>>>>>>
>>>>>> The DSDT defines the CPLS field at EC offset 0x0F, bit 7.
>>>>>>
>>>>>> Reading that byte through the read-only ec_sys interface showed it changing
>>>>>> from 0x00 to 0x80 when Caps Lock was toggled.
>>>>>>
>>>>>> Enabling dynamic debugging in drivers/acpi/ec.c confirmed that each Caps
>>>>>> Lock press triggered EC query 0x78, which was scheduled, started and
>>>>>> stopped successfully.
>>>>>>
>>>>>> *3. Lenovo's firmware controls GPIO 11*
>>>>>>
>>>>>> The DSDT contains:
>>>>>>
>>>>>> Method (_Q78, 0, NotSerialized)
>>>>>> {
>>>>>> If (CPLS)
>>>>>> {
>>>>>> WFIO (0x0B, 0x00)
>>>>>> }
>>>>>> Else
>>>>>> {
>>>>>> WFIO (0x0B, 0x01)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The WFIO method writes bit 22 using WMEM(), targeting address 0xFED81500 +
>>>>>> (11 * 4) = 0xFED8152C.
>>>>>>
>>>>>> This appears to control the Caps Lock indicator using GPIO 11.
>>>>>>
>>>>>> *4. The same GPIO is declared as an ACPI interrupt*
>>>>>>
>>>>>> In SSDT12, _SB.GPIO._AEI declares GPIO 11 as an edge-triggered, active-low,
>>>>>> exclusive wake interrupt.
>>>>>>
>>>>>> Its _EVT handler includes:
>>>>>>
>>>>>> Case (0x0B)
>>>>>> {
>>>>>> MSTP (0x3911)
>>>>>> Notify (\_SB.PCI0.GPP1, 0x00) // Bus Check
>>>>
>>>> This looks like some GPIO related notification. I dunno what Windows driver does.
>>>> Mario?
>>>>
>>>
>>> Honestly - this sounds like a copy / paste BIOS bug that they copied the
>>> SSDT from one system and didn't change it.
>>>
>>> I would think quirking it makes sense if the BIOS isn't going to be fixed.
>>>
>>> Before we go much further can you check if this is the latest BIOS?
>>> Check Lenovo's website, in case it wasn't brought to LVFS.
>>>
>>> Also; Mark can you ask BIOS guys to look this over?
>>>
>>> It sure seems like GPIO 11 shouldn't be in _AEI.
>>>
>> Yep - created internal ticket LO-4711
>> Just a note though - the platform was not in the Linux program (and is rather old) - so my expectations of getting a fix is rather low I'm afraid
>>
>> I'd get the quirk ready, and if I don't get any feedback from the FW team by next week go ahead with that.
>>
>> Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-10-15 20:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAAUQFRPW-rbcZV-=qV1NMjF_358sdJTiGvQuRxRqAsehY+J9Qg@mail.gmail.com>
2026-10-15 18:25 ` ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict Andy Shevchenko
2026-10-15 18:31 ` Andy Shevchenko
2026-10-15 18:48 ` Mario Limonciello
2026-10-15 19:24 ` Mark Pearson
2026-10-15 20:13 ` Nikodem Sanecki
2026-10-15 20:26 ` Mario Limonciello
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®