pcengines_apuv2: LEDs/Input fails since v6.18

pcengines_apuv2: LEDs/Input fails since v6.18

[Tj]

Installed v6.19 recently and realised the heartbeat/network LED 
configuration I'd set wasn't working. Checking the log I see:

kernel: platform gpio-keys-polled: deferred probe pending: 
gpio-keys-polled: failed to get gpio
kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to 
get GPIO 'apu2-leds/led-1'

Looking through commits I found b8754092dfed4fc2fc

platform/x86: pcengines-apuv2: Use static device properties

After reverting it the LEDs operate as expected. This entered in v6.18 
so will affect it as well.

In v6.17 I see:

kernel: platform gpio-keys-polled: deferred probe pending: 
gpio-keys-polled: unable to claim gpio 0

that is a slight variation on the v6.19 report. I've not pin-pointed the 
cause yet.

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Hans de Goede]

Hi,

On 16-Feb-26 20:01, Tj wrote:
> Installed v6.19 recently and realised the heartbeat/network LED 
> configuration I'd set wasn't working. Checking the log I see:
> 
> kernel: platform gpio-keys-polled: deferred probe pending: 
> gpio-keys-polled: failed to get gpio
> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to 
> get GPIO 'apu2-leds/led-1'
> 
> Looking through commits I found b8754092dfed4fc2fc
> 
> platform/x86: pcengines-apuv2: Use static device properties
> 
> After reverting it the LEDs operate as expected. This entered in v6.18 
> so will affect it as well.
> 
> In v6.17 I see:
> 
> kernel: platform gpio-keys-polled: deferred probe pending: 
> gpio-keys-polled: unable to claim gpio 0
> 
> that is a slight variation on the v6.19 report. I've not pin-pointed the 
> cause yet.

This should be fixed by this patch:

https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/

If possible, please give a kernel with that patch added a spin
and confirm if it fixes things.

Regards,

Hans

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Tj]

On 17/02/2026 11:42, Hans de Goede wrote:
> On 16-Feb-26 20:01, Tj wrote:
>> Installed v6.19 recently and realised the heartbeat/network LED
>> configuration I'd set wasn't working. Checking the log I see:
>>
>> kernel: platform gpio-keys-polled: deferred probe pending:
>> gpio-keys-polled: failed to get gpio
>> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to
>> get GPIO 'apu2-leds/led-1'
>>
>> Looking through commits I found b8754092dfed4fc2fc
>>
>> platform/x86: pcengines-apuv2: Use static device properties
>>
>> After reverting it the LEDs operate as expected. This entered in v6.18
>> so will affect it as well.
>>
>> In v6.17 I see:
>>
>> kernel: platform gpio-keys-polled: deferred probe pending:
>> gpio-keys-polled: unable to claim gpio 0
>>
>> that is a slight variation on the v6.19 report. I've not pin-pointed the
>> cause yet.
> This should be fixed by this patch:
>
> https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/
>
> If possible, please give a kernel with that patch added a spin
> and confirm if it fixes things.

It fixes the LED issue but causes massive log spamming (10's per second) 
related to the gpio-keys-polled:

[    0.000000] Linux version 6.19.2+debian+tj (linux@iam.tj) (gcc 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #404 
SMP PREEMPT_DYNAMIC Tue Feb 17 14:19:16 UTC 2026
...
[    0.000000] DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 01/31/2023
...
[    6.025741] input: gpio-keys-polled as 
/devices/platform/gpio-keys-polled/input/input0
[    6.035231] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
...
[   19.545273] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
...
[   21.742226] input: PC Speaker as /devices/platform/pcspkr/input/input2
...
[  OK  ] Started dbus.service - D-Bus System Message Bus.
[  OK  ] Finished e2scrub_reap.service - Re…line ext4 Metadata Check 
Snapshots.
[  OK  ] Started virtlockd.service - libvirt locking daemon.
[  OK  ] Started 819142] gpio   32.-keys-polled gpio  32.-keys-polled: 
failed to get gpio   32. state: -52
1;39msystemd-machined.service -…and Container Registration Service.
[  OK  ] Started systemd-logind.service - User Login Management.
[   32.930711] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
[  OK  ] Finished grub2-common.service - Record successful boot for GRUB.
[   33.050784] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
[  OK  ] Started polkit.service - Authorization Manager.
          Starting ModemManager.service - Modem Manager...
[  OK  ] Started virtlogd.service - libvirt logging daemon.
[   33.158927] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
[   33.266709] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
[   33.374696] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
[   33.486644] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
[   33.580268] NET: Registered PF_QIPCRTR protocol family
[   33.594700] gpio-keys-polled gpio-keys-polled: failed to get gpio 
state: -52
...

 From that point onwards the message is repeated approximately 10 per 
second.

It isn't quite clear what triggered it because the log messages between 
kernel and systemd are mixed up there but I suspect it is systemd-logind.

$ errno  <<< "error -52"
error -52 (EBADE Invalid exchange) found in /usr/include/asm-generic/errno.h

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Dmitry Torokhov]

On Tue, Feb 17, 2026 at 03:25:01PM +0000, Tj wrote:
> On 17/02/2026 11:42, Hans de Goede wrote:
> > On 16-Feb-26 20:01, Tj wrote:
> >> Installed v6.19 recently and realised the heartbeat/network LED
> >> configuration I'd set wasn't working. Checking the log I see:
> >>
> >> kernel: platform gpio-keys-polled: deferred probe pending:
> >> gpio-keys-polled: failed to get gpio
> >> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to
> >> get GPIO 'apu2-leds/led-1'
> >>
> >> Looking through commits I found b8754092dfed4fc2fc
> >>
> >> platform/x86: pcengines-apuv2: Use static device properties
> >>
> >> After reverting it the LEDs operate as expected. This entered in v6.18
> >> so will affect it as well.
> >>
> >> In v6.17 I see:
> >>
> >> kernel: platform gpio-keys-polled: deferred probe pending:
> >> gpio-keys-polled: unable to claim gpio 0
> >>
> >> that is a slight variation on the v6.19 report. I've not pin-pointed the
> >> cause yet.
> > This should be fixed by this patch:
> >
> > https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/
> >
> > If possible, please give a kernel with that patch added a spin
> > and confirm if it fixes things.
> 
> It fixes the LED issue but causes massive log spamming (10's per second) 
> related to the gpio-keys-polled:
> 
> [    0.000000] Linux version 6.19.2+debian+tj (linux@iam.tj) (gcc 
> (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #404 
> SMP PREEMPT_DYNAMIC Tue Feb 17 14:19:16 UTC 2026
> ...
> [    0.000000] DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 01/31/2023
> ...
> [    6.025741] input: gpio-keys-polled as 
> /devices/platform/gpio-keys-polled/input/input0
> [    6.035231] gpio-keys-polled gpio-keys-polled: failed to get gpio 
> state: -52
> ...
> [   19.545273] input: Power Button as 
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> ...
> [   21.742226] input: PC Speaker as /devices/platform/pcspkr/input/input2
> ...
> [  OK  ] Started dbus.service - D-Bus System Message Bus.
> [  OK  ] Finished e2scrub_reap.service - Re…line ext4 Metadata Check 
> Snapshots.
> [  OK  ] Started virtlockd.service - libvirt locking daemon.
> [  OK  ] Started 819142] gpio   32.-keys-polled gpio  32.-keys-polled: 
> failed to get gpio   32. state: -52
> 1;39msystemd-machined.service -…and Container Registration Service.
> [  OK  ] Started systemd-logind.service - User Login Management.
> [   32.930711] gpio-keys-polled gpio-keys-polled: failed to get gpio 
> state: -52
> [  OK  ] Finished grub2-common.service - Record successful boot for GRUB.
> [   33.050784] gpio-keys-polled gpio-keys-polled: failed to get gpio 
> state: -52
> [  OK  ] Started polkit.service - Authorization Manager.
>           Starting ModemManager.service - Modem Manager...
> [  OK  ] Started virtlogd.service - libvirt logging daemon.
> [   33.158927] gpio-keys-polled gpio-keys-polled: failed to get gpio 
> state: -52

I think the patch below should fix it.

Bartosz, I think you should revert
86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
existing gpio drivers. Breakign the kernel like that is not great.

Thanks.

-- 
Dmitry


diff --git a/drivers/gpio/gpio-amd-fch.c b/drivers/gpio/gpio-amd-fch.c
index e6c6c3ec7656..9f329938202b 100644
--- a/drivers/gpio/gpio-amd-fch.c
+++ b/drivers/gpio/gpio-amd-fch.c
@@ -8,6 +8,7 @@
  *
  */
 
+#include <linux/bitfield.h>
 #include <linux/err.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
@@ -120,15 +121,15 @@ static int amd_fch_gpio_get(struct gpio_chip *gc,
 			    unsigned int offset)
 {
 	unsigned long flags;
-	int ret;
+	u32 val;
 	struct amd_fch_gpio_priv *priv = gpiochip_get_data(gc);
 	void __iomem *ptr = amd_fch_gpio_addr(priv, offset);
 
 	spin_lock_irqsave(&priv->lock, flags);
-	ret = (readl_relaxed(ptr) & AMD_FCH_GPIO_FLAG_READ);
+	val = readl_relaxed(ptr);
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-	return ret;
+	return FIELD_GET(AMD_FCH_GPIO_FLAG_READ, val);
 }
 
 static int amd_fch_gpio_request(struct gpio_chip *chip,

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Tj]

On 17/02/2026 17:29, Dmitry Torokhov wrote:
> On Tue, Feb 17, 2026 at 03:25:01PM +0000, Tj wrote:
>> On 17/02/2026 11:42, Hans de Goede wrote:
>>> On 16-Feb-26 20:01, Tj wrote:
>>>> Installed v6.19 recently and realised the heartbeat/network LED
>>>> configuration I'd set wasn't working. Checking the log I see:
>>>>
>>>> kernel: platform gpio-keys-polled: deferred probe pending:
>>>> gpio-keys-polled: failed to get gpio
>>>> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to
>>>> get GPIO 'apu2-leds/led-1'
>>>>
>>>> Looking through commits I found b8754092dfed4fc2fc
>>>>
>>>> platform/x86: pcengines-apuv2: Use static device properties
>>>>
>>>> After reverting it the LEDs operate as expected. This entered in v6.18
>>>> so will affect it as well.
>>>>
>>>> In v6.17 I see:
>>>>
>>>> kernel: platform gpio-keys-polled: deferred probe pending:
>>>> gpio-keys-polled: unable to claim gpio 0
>>>>
>>>> that is a slight variation on the v6.19 report. I've not pin-pointed the
>>>> cause yet.
>>> This should be fixed by this patch:
>>>
>>> https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/
>>>
>>> If possible, please give a kernel with that patch added a spin
>>> and confirm if it fixes things.
>> It fixes the LED issue but causes massive log spamming (10's per second)
>> related to the gpio-keys-polled:
>>
>> [    0.000000] Linux version 6.19.2+debian+tj (linux@iam.tj) (gcc
>> (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #404
>> SMP PREEMPT_DYNAMIC Tue Feb 17 14:19:16 UTC 2026
>> ...
>> [    0.000000] DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 01/31/2023
>> ...
>> [    6.025741] input: gpio-keys-polled as
>> /devices/platform/gpio-keys-polled/input/input0
>> [    6.035231] gpio-keys-polled gpio-keys-polled: failed to get gpio
>> state: -52
>> ...
>> [   19.545273] input: Power Button as
>> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
>> ...
>> [   21.742226] input: PC Speaker as /devices/platform/pcspkr/input/input2
>> ...
>> [  OK  ] Started dbus.service - D-Bus System Message Bus.
>> [  OK  ] Finished e2scrub_reap.service - Re…line ext4 Metadata Check
>> Snapshots.
>> [  OK  ] Started virtlockd.service - libvirt locking daemon.
>> [  OK  ] Started 819142] gpio   32.-keys-polled gpio  32.-keys-polled:
>> failed to get gpio   32. state: -52
>> 1;39msystemd-machined.service -…and Container Registration Service.
>> [  OK  ] Started systemd-logind.service - User Login Management.
>> [   32.930711] gpio-keys-polled gpio-keys-polled: failed to get gpio
>> state: -52
>> [  OK  ] Finished grub2-common.service - Record successful boot for GRUB.
>> [   33.050784] gpio-keys-polled gpio-keys-polled: failed to get gpio
>> state: -52
>> [  OK  ] Started polkit.service - Authorization Manager.
>>            Starting ModemManager.service - Modem Manager...
>> [  OK  ] Started virtlogd.service - libvirt logging daemon.
>> [   33.158927] gpio-keys-polled gpio-keys-polled: failed to get gpio
>> state: -52
> I think the patch below should fix it.
>
> Bartosz, I think you should revert
> 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> existing gpio drivers. Breakign the kernel like that is not great.
>
> Thanks.
>
> --
> Dmitry
>
>
> diff --git a/drivers/gpio/gpio-amd-fch.c b/drivers/gpio/gpio-amd-fch.c
> index e6c6c3ec7656..9f329938202b 100644
> --- a/drivers/gpio/gpio-amd-fch.c
> +++ b/drivers/gpio/gpio-amd-fch.c
> @@ -8,6 +8,7 @@
>    *
>    */
>
> +#include <linux/bitfield.h>
>   #include <linux/err.h>
>   #include <linux/io.h>
>   #include <linux/kernel.h>
> @@ -120,15 +121,15 @@ static int amd_fch_gpio_get(struct gpio_chip *gc,
>   			    unsigned int offset)
>   {
>   	unsigned long flags;
> -	int ret;
> +	u32 val;
>   	struct amd_fch_gpio_priv *priv = gpiochip_get_data(gc);
>   	void __iomem *ptr = amd_fch_gpio_addr(priv, offset);
>
>   	spin_lock_irqsave(&priv->lock, flags);
> -	ret = (readl_relaxed(ptr) & AMD_FCH_GPIO_FLAG_READ);
> +	val = readl_relaxed(ptr);
>   	spin_unlock_irqrestore(&priv->lock, flags);
>
> -	return ret;
> +	return FIELD_GET(AMD_FCH_GPIO_FLAG_READ, val);
>   }
>
>   static int amd_fch_gpio_request(struct gpio_chip *chip,

Thank-you - that does appear to have cleared the errors. I've now got to 
find the docs and remind myself what the GPIO inputs actually do!

tj@apu2:~$ journalctl --boot 0 --grep 'gpio'
Feb 17 19:28:57 apu2 kernel: input: gpio-keys-polled as 
/devices/platform/gpio-keys-polled/input/input0
Feb 17 19:29:13 apu2 systemd-logind[821]: Watching system buttons on 
/dev/input/event0 (gpio-keys-polled)
tj@apu2:~$ journalctl --boot 0 --grep 'input'
Feb 17 19:28:57 apu2 kernel: input: gpio-keys-polled as 
/devices/platform/gpio-keys-polled/input/input0
Feb 17 19:29:01 apu2 kernel: input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
Feb 17 19:29:02 apu2 kernel: input: PC Speaker as 
/devices/platform/pcspkr/input/input2
Feb 17 19:29:13 apu2 systemd-logind[821]: Watching system buttons on 
/dev/input/event1 (Power Button)
Feb 17 19:29:13 apu2 systemd-logind[821]: Watching system buttons on 
/dev/input/event0 (gpio-keys-polled)
tj@apu2:~$ journalctl --boot 0 --grep 'apu2'
Feb 17 19:28:57 apu2 kernel: DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 
01/31/2023
Feb 17 19:28:57 apu2 systemd[1]: Hostname set to <apu2>.
Feb 17 19:28:58 apu2 systemd[1]: Mounting srv-NAS-Apu2-rootfs.mount - 
/srv/NAS/Apu2/rootfs...
Feb 17 19:28:58 apu2 systemd[1]: Mounted srv-NAS-Apu2-rootfs.mount - 
/srv/NAS/Apu2/rootfs.
Feb 17 19:28:59 apu2 systemd-resolved[436]: Using system hostname 'apu2'.
Feb 17 19:29:01 apu2 systemd[1]: Mounting 
srv-NAS-Apu2-current\x2dcost.mount - /srv/NAS/Apu2/current-cost...
Feb 17 19:29:02 apu2 systemd[1]: Mounted 
srv-NAS-Apu2-current\x2dcost.mount - /srv/NAS/Apu2/current-cost.
Feb 17 19:29:12 apu2 systemd[1]: Starting apu2-led-triggers.service - 
Enable system performance feedback via the 3 front LEDs on PC Engines 
APU2...
Feb 17 19:29:15 apu2 systemd[1]: Finished apu2-led-triggers.service - 
Enable system performance feedback via the 3 front LEDs on PC Engines APU2.

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Bartosz Golaszewski]

On Tue, Feb 17, 2026 at 6:29 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Tue, Feb 17, 2026 at 03:25:01PM +0000, Tj wrote:
> > On 17/02/2026 11:42, Hans de Goede wrote:
> > > On 16-Feb-26 20:01, Tj wrote:
> > >> Installed v6.19 recently and realised the heartbeat/network LED
> > >> configuration I'd set wasn't working. Checking the log I see:
> > >>
> > >> kernel: platform gpio-keys-polled: deferred probe pending:
> > >> gpio-keys-polled: failed to get gpio
> > >> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to
> > >> get GPIO 'apu2-leds/led-1'
> > >>
> > >> Looking through commits I found b8754092dfed4fc2fc
> > >>
> > >> platform/x86: pcengines-apuv2: Use static device properties
> > >>
> > >> After reverting it the LEDs operate as expected. This entered in v6.18
> > >> so will affect it as well.
> > >>
> > >> In v6.17 I see:
> > >>
> > >> kernel: platform gpio-keys-polled: deferred probe pending:
> > >> gpio-keys-polled: unable to claim gpio 0
> > >>
> > >> that is a slight variation on the v6.19 report. I've not pin-pointed the
> > >> cause yet.
> > > This should be fixed by this patch:
> > >
> > > https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/
> > >
> > > If possible, please give a kernel with that patch added a spin
> > > and confirm if it fixes things.
> >
> > It fixes the LED issue but causes massive log spamming (10's per second)
> > related to the gpio-keys-polled:
> >
> > [    0.000000] Linux version 6.19.2+debian+tj (linux@iam.tj) (gcc
> > (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #404
> > SMP PREEMPT_DYNAMIC Tue Feb 17 14:19:16 UTC 2026
> > ...
> > [    0.000000] DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 01/31/2023
> > ...
> > [    6.025741] input: gpio-keys-polled as
> > /devices/platform/gpio-keys-polled/input/input0
> > [    6.035231] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > state: -52
> > ...
> > [   19.545273] input: Power Button as
> > /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> > ...
> > [   21.742226] input: PC Speaker as /devices/platform/pcspkr/input/input2
> > ...
> > [  OK  ] Started dbus.service - D-Bus System Message Bus.
> > [  OK  ] Finished e2scrub_reap.service - Re…line ext4 Metadata Check
> > Snapshots.
> > [  OK  ] Started virtlockd.service - libvirt locking daemon.
> > [  OK  ] Started 819142] gpio   32.-keys-polled gpio  32.-keys-polled:
> > failed to get gpio   32. state: -52
> > 1;39msystemd-machined.service -…and Container Registration Service.
> > [  OK  ] Started systemd-logind.service - User Login Management.
> > [   32.930711] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > state: -52
> > [  OK  ] Finished grub2-common.service - Record successful boot for GRUB.
> > [   33.050784] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > state: -52
> > [  OK  ] Started polkit.service - Authorization Manager.
> >           Starting ModemManager.service - Modem Manager...
> > [  OK  ] Started virtlogd.service - libvirt logging daemon.
> > [   33.158927] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > state: -52
>
> I think the patch below should fix it.
>
> Bartosz, I think you should revert
> 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> existing gpio drivers. Breakign the kernel like that is not great.
>

Hi Dmitry!

This change has been upstream for close to a year - it first appeared
in v6.15-rc1. There have been very few reports (I think a couple
initially and then none for months) and fixing this is typically
trivial. It addressed an actual problem where these retvals would be
propagated to user-space and misinterpreted. I think we should fix
this driver and keep this change. "Auditing" typically means never
fixing things entirely.

Bartosz

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Dmitry Torokhov]

On Wed, Feb 18, 2026 at 10:55:46AM +0100, Bartosz Golaszewski wrote:
> On Tue, Feb 17, 2026 at 6:29 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Tue, Feb 17, 2026 at 03:25:01PM +0000, Tj wrote:
> > > On 17/02/2026 11:42, Hans de Goede wrote:
> > > > On 16-Feb-26 20:01, Tj wrote:
> > > >> Installed v6.19 recently and realised the heartbeat/network LED
> > > >> configuration I'd set wasn't working. Checking the log I see:
> > > >>
> > > >> kernel: platform gpio-keys-polled: deferred probe pending:
> > > >> gpio-keys-polled: failed to get gpio
> > > >> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to
> > > >> get GPIO 'apu2-leds/led-1'
> > > >>
> > > >> Looking through commits I found b8754092dfed4fc2fc
> > > >>
> > > >> platform/x86: pcengines-apuv2: Use static device properties
> > > >>
> > > >> After reverting it the LEDs operate as expected. This entered in v6.18
> > > >> so will affect it as well.
> > > >>
> > > >> In v6.17 I see:
> > > >>
> > > >> kernel: platform gpio-keys-polled: deferred probe pending:
> > > >> gpio-keys-polled: unable to claim gpio 0
> > > >>
> > > >> that is a slight variation on the v6.19 report. I've not pin-pointed the
> > > >> cause yet.
> > > > This should be fixed by this patch:
> > > >
> > > > https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/
> > > >
> > > > If possible, please give a kernel with that patch added a spin
> > > > and confirm if it fixes things.
> > >
> > > It fixes the LED issue but causes massive log spamming (10's per second)
> > > related to the gpio-keys-polled:
> > >
> > > [    0.000000] Linux version 6.19.2+debian+tj (linux@iam.tj) (gcc
> > > (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #404
> > > SMP PREEMPT_DYNAMIC Tue Feb 17 14:19:16 UTC 2026
> > > ...
> > > [    0.000000] DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 01/31/2023
> > > ...
> > > [    6.025741] input: gpio-keys-polled as
> > > /devices/platform/gpio-keys-polled/input/input0
> > > [    6.035231] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > state: -52
> > > ...
> > > [   19.545273] input: Power Button as
> > > /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> > > ...
> > > [   21.742226] input: PC Speaker as /devices/platform/pcspkr/input/input2
> > > ...
> > > [  OK  ] Started dbus.service - D-Bus System Message Bus.
> > > [  OK  ] Finished e2scrub_reap.service - Re…line ext4 Metadata Check
> > > Snapshots.
> > > [  OK  ] Started virtlockd.service - libvirt locking daemon.
> > > [  OK  ] Started 819142] gpio   32.-keys-polled gpio  32.-keys-polled:
> > > failed to get gpio   32. state: -52
> > > 1;39msystemd-machined.service -…and Container Registration Service.
> > > [  OK  ] Started systemd-logind.service - User Login Management.
> > > [   32.930711] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > state: -52
> > > [  OK  ] Finished grub2-common.service - Record successful boot for GRUB.
> > > [   33.050784] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > state: -52
> > > [  OK  ] Started polkit.service - Authorization Manager.
> > >           Starting ModemManager.service - Modem Manager...
> > > [  OK  ] Started virtlogd.service - libvirt logging daemon.
> > > [   33.158927] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > state: -52
> >
> > I think the patch below should fix it.
> >
> > Bartosz, I think you should revert
> > 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> > existing gpio drivers. Breakign the kernel like that is not great.
> >
> 
> Hi Dmitry!
> 
> This change has been upstream for close to a year - it first appeared
> in v6.15-rc1. There have been very few reports (I think a couple
> initially and then none for months) and fixing this is typically
> trivial. It addressed an actual problem where these retvals would be
> propagated to user-space and misinterpreted. I think we should fix
> this driver and keep this change. "Auditing" typically means never
> fixing things entirely.

[+LinusW as co-maintainer]

That's ... an interesting stance. You couldn't even bother going
through your own subsystem before applying a change that could break
user's systems.

Here is your first approximation from gemini:

Based on my analysis of the drivers in kernel/linux-next/drivers/gpio/, the following drivers have GPIO line getters that return values outside
  the expected [0, 1] range (when they should return normalized boolean values) or a negative error code:


   1. `gpio-bd9571mwv.c`: bd9571mwv_gpio_get() returns val & BIT(offset), which can be any power of 2 depending on the offset.
   2. `gpio-cgbc.c`: cgbc_gpio_get() returns (int)(val & (u8)BIT(offset)), which is not normalized to 0 or 1.
   3. `gpio-da9055.c`: da9055_gpio_get() returns ret & (1 << offset), which is not normalized.
   4. `gpio-lp873x.c`: lp873x_gpio_get() returns val & BIT(offset * BITS_PER_GPO), which is not normalized.
   5. `gpio-stp-xway.c`: xway_stp_get() returns (xway_stp_r32(chip->virt, XWAY_STP_CPU0) & BIT(gpio)), which is not normalized.
   6. `gpio-tps65086.c`: tps65086_gpio_get() returns val & BIT(4 + offset), which is not normalized.
   7. `gpio-viperboard.c`: vprbrd_gpiob_get() returns gpio->gpiob_val & (1 << offset) in the branch where the GPIO is configured as an output.

Thanks.

-- 
Dmitry

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Dmitry Torokhov]

On Wed, Feb 18, 2026 at 09:25:15AM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 18, 2026 at 10:55:46AM +0100, Bartosz Golaszewski wrote:
> > On Tue, Feb 17, 2026 at 6:29 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > On Tue, Feb 17, 2026 at 03:25:01PM +0000, Tj wrote:
> > > > On 17/02/2026 11:42, Hans de Goede wrote:
> > > > > On 16-Feb-26 20:01, Tj wrote:
> > > > >> Installed v6.19 recently and realised the heartbeat/network LED
> > > > >> configuration I'd set wasn't working. Checking the log I see:
> > > > >>
> > > > >> kernel: platform gpio-keys-polled: deferred probe pending:
> > > > >> gpio-keys-polled: failed to get gpio
> > > > >> kernel: platform leds-gpio: deferred probe pending: leds-gpio: Failed to
> > > > >> get GPIO 'apu2-leds/led-1'
> > > > >>
> > > > >> Looking through commits I found b8754092dfed4fc2fc
> > > > >>
> > > > >> platform/x86: pcengines-apuv2: Use static device properties
> > > > >>
> > > > >> After reverting it the LEDs operate as expected. This entered in v6.18
> > > > >> so will affect it as well.
> > > > >>
> > > > >> In v6.17 I see:
> > > > >>
> > > > >> kernel: platform gpio-keys-polled: deferred probe pending:
> > > > >> gpio-keys-polled: unable to claim gpio 0
> > > > >>
> > > > >> that is a slight variation on the v6.19 report. I've not pin-pointed the
> > > > >> cause yet.
> > > > > This should be fixed by this patch:
> > > > >
> > > > > https://lore.kernel.org/linux-gpio/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com/
> > > > >
> > > > > If possible, please give a kernel with that patch added a spin
> > > > > and confirm if it fixes things.
> > > >
> > > > It fixes the LED issue but causes massive log spamming (10's per second)
> > > > related to the gpio-keys-polled:
> > > >
> > > > [    0.000000] Linux version 6.19.2+debian+tj (linux@iam.tj) (gcc
> > > > (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #404
> > > > SMP PREEMPT_DYNAMIC Tue Feb 17 14:19:16 UTC 2026
> > > > ...
> > > > [    0.000000] DMI: PC Engines apu2/apu2, BIOS v4.19.0.1 01/31/2023
> > > > ...
> > > > [    6.025741] input: gpio-keys-polled as
> > > > /devices/platform/gpio-keys-polled/input/input0
> > > > [    6.035231] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > > state: -52
> > > > ...
> > > > [   19.545273] input: Power Button as
> > > > /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> > > > ...
> > > > [   21.742226] input: PC Speaker as /devices/platform/pcspkr/input/input2
> > > > ...
> > > > [  OK  ] Started dbus.service - D-Bus System Message Bus.
> > > > [  OK  ] Finished e2scrub_reap.service - Re…line ext4 Metadata Check
> > > > Snapshots.
> > > > [  OK  ] Started virtlockd.service - libvirt locking daemon.
> > > > [  OK  ] Started 819142] gpio   32.-keys-polled gpio  32.-keys-polled:
> > > > failed to get gpio   32. state: -52
> > > > 1;39msystemd-machined.service -…and Container Registration Service.
> > > > [  OK  ] Started systemd-logind.service - User Login Management.
> > > > [   32.930711] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > > state: -52
> > > > [  OK  ] Finished grub2-common.service - Record successful boot for GRUB.
> > > > [   33.050784] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > > state: -52
> > > > [  OK  ] Started polkit.service - Authorization Manager.
> > > >           Starting ModemManager.service - Modem Manager...
> > > > [  OK  ] Started virtlogd.service - libvirt logging daemon.
> > > > [   33.158927] gpio-keys-polled gpio-keys-polled: failed to get gpio
> > > > state: -52
> > >
> > > I think the patch below should fix it.
> > >
> > > Bartosz, I think you should revert
> > > 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> > > existing gpio drivers. Breakign the kernel like that is not great.
> > >
> > 
> > Hi Dmitry!
> > 
> > This change has been upstream for close to a year - it first appeared
> > in v6.15-rc1. There have been very few reports (I think a couple
> > initially and then none for months) and fixing this is typically
> > trivial. It addressed an actual problem where these retvals would be
> > propagated to user-space and misinterpreted. I think we should fix
> > this driver and keep this change. "Auditing" typically means never
> > fixing things entirely.
> 
> [+LinusW as co-maintainer]
> 
> That's ... an interesting stance. You couldn't even bother going
> through your own subsystem before applying a change that could break
> user's systems.
> 
> Here is your first approximation from gemini:
> 
> Based on my analysis of the drivers in kernel/linux-next/drivers/gpio/, the following drivers have GPIO line getters that return values outside
>   the expected [0, 1] range (when they should return normalized boolean values) or a negative error code:
> 
> 
>    1. `gpio-bd9571mwv.c`: bd9571mwv_gpio_get() returns val & BIT(offset), which can be any power of 2 depending on the offset.
>    2. `gpio-cgbc.c`: cgbc_gpio_get() returns (int)(val & (u8)BIT(offset)), which is not normalized to 0 or 1.
>    3. `gpio-da9055.c`: da9055_gpio_get() returns ret & (1 << offset), which is not normalized.
>    4. `gpio-lp873x.c`: lp873x_gpio_get() returns val & BIT(offset * BITS_PER_GPO), which is not normalized.
>    5. `gpio-stp-xway.c`: xway_stp_get() returns (xway_stp_r32(chip->virt, XWAY_STP_CPU0) & BIT(gpio)), which is not normalized.
>    6. `gpio-tps65086.c`: tps65086_gpio_get() returns val & BIT(4 + offset), which is not normalized.
>    7. `gpio-viperboard.c`: vprbrd_gpiob_get() returns gpio->gpiob_val & (1 << offset) in the branch where the GPIO is configured as an output.

And more to consider:

✦ The following drivers have GPIO get methods that return non-normalized values (values other than 0, 1, or a negative error code):


   * `drivers/iio/adc/ti-ads7950.c`: ti_ads7950_get() returns a bitmask for output pins.
   * `drivers/media/i2c/max9286.c`: max9286_gpiochip_get() returns a bitmask.
   * `drivers/net/phy/qcom/qca807x.c`: qca807x_gpio_get() returns a 2-bit field (0–3).
   * `drivers/pinctrl/renesas/pinctrl-rza1.c`: rza1_gpio_get() returns a bitmask.
   * `drivers/platform/x86/barco-p50-gpio.c`: p50_gpio_get() returns a raw register byte.
   * `drivers/power/supply/sbs-manager.c`: sbsm_gpio_get_value() returns a bitmask.

Thanks.

-- 
Dmitry

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Bartosz Golaszewski]

On Wed, Feb 18, 2026 at 6:25 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> > >
> > > I think the patch below should fix it.
> > >
> > > Bartosz, I think you should revert
> > > 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> > > existing gpio drivers. Breakign the kernel like that is not great.
> > >
> >
> > Hi Dmitry!
> >
> > This change has been upstream for close to a year - it first appeared
> > in v6.15-rc1. There have been very few reports (I think a couple
> > initially and then none for months) and fixing this is typically
> > trivial. It addressed an actual problem where these retvals would be
> > propagated to user-space and misinterpreted. I think we should fix
> > this driver and keep this change. "Auditing" typically means never
> > fixing things entirely.
>
> [+LinusW as co-maintainer]
>
> That's ... an interesting stance. You couldn't even bother going
> through your own subsystem before applying a change that could break
> user's systems.
>

My stance is that I don't want a knee-jerk reaction of reverting a
valid change after one report (with a fix queued) several months after
the change was made. If more people start complaining then I won't
oppose a revert.

> Here is your first approximation from gemini:
>
> Based on my analysis of the drivers in kernel/linux-next/drivers/gpio/, the following drivers have GPIO line getters that return values outside
>   the expected [0, 1] range (when they should return normalized boolean values) or a negative error code:
>
>
>    1. `gpio-bd9571mwv.c`: bd9571mwv_gpio_get() returns val & BIT(offset), which can be any power of 2 depending on the offset.
>    2. `gpio-cgbc.c`: cgbc_gpio_get() returns (int)(val & (u8)BIT(offset)), which is not normalized to 0 or 1.
>    3. `gpio-da9055.c`: da9055_gpio_get() returns ret & (1 << offset), which is not normalized.
>    4. `gpio-lp873x.c`: lp873x_gpio_get() returns val & BIT(offset * BITS_PER_GPO), which is not normalized.
>    5. `gpio-stp-xway.c`: xway_stp_get() returns (xway_stp_r32(chip->virt, XWAY_STP_CPU0) & BIT(gpio)), which is not normalized.
>    6. `gpio-tps65086.c`: tps65086_gpio_get() returns val & BIT(4 + offset), which is not normalized.
>    7. `gpio-viperboard.c`: vprbrd_gpiob_get() returns gpio->gpiob_val & (1 << offset) in the branch where the GPIO is configured as an output.
>

Touché. I will go through these and fix them instead of reverting the
patch, does it sound good?

Bartosz

Re: pcengines_apuv2: LEDs/Input fails since v6.18

[Dmitry Torokhov]

On Wed, Feb 18, 2026 at 09:21:14PM +0100, Bartosz Golaszewski wrote:
> On Wed, Feb 18, 2026 at 6:25 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > > >
> > > > I think the patch below should fix it.
> > > >
> > > > Bartosz, I think you should revert
> > > > 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> > > > existing gpio drivers. Breakign the kernel like that is not great.
> > > >
> > >
> > > Hi Dmitry!
> > >
> > > This change has been upstream for close to a year - it first appeared
> > > in v6.15-rc1. There have been very few reports (I think a couple
> > > initially and then none for months) and fixing this is typically
> > > trivial. It addressed an actual problem where these retvals would be
> > > propagated to user-space and misinterpreted. I think we should fix
> > > this driver and keep this change. "Auditing" typically means never
> > > fixing things entirely.
> >
> > [+LinusW as co-maintainer]
> >
> > That's ... an interesting stance. You couldn't even bother going
> > through your own subsystem before applying a change that could break
> > user's systems.
> >
> 
> My stance is that I don't want a knee-jerk reaction of reverting a
> valid change after one report (with a fix queued) several months after
> the change was made. If more people start complaining then I won't
> oppose a revert.

I think you are witnessing that outside of "common" x86 devices there is
significant lag between the latest kernel release and what people are
actually using on their systems.

Thanks.

-- 
Dmitry