Re: ThinkPad L13 Gen 2 AMD (21AB): Caps Lock LED broken by ACPI GPIO 11 interrupt conflict

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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