mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* 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 AMDI0...
@ 2026-10-15 14:21 Nikodem Sanecki
  2026-10-15 18:18 ` Andy Shevchenko
  0 siblings, 1 reply; 3+ messages in thread
From: Nikodem Sanecki @ 2026-10-15 14:21 UTC (permalink / raw)
  To: westeri, andriy.shevchenko; +Cc: linux-gpio, linux-acpi, linux-kernel

Resending this report in plain text because my original email was
rejected by the linux-gpio and linux-kernel mailing lists for
containing HTML formatting. Apologies if you received the original
message twice.


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.

Best regards

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-15 18:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-15 14:21 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 AMDI0 Nikodem Sanecki
2026-10-15 18:18 ` Andy Shevchenko
2026-10-15 18:32   ` Andy Shevchenko

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®