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

[Mario Limonciello <mario.limonciello@amd.com>]

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