pcengines_apuv2: LEDs/Input fails since v6.18

DISCUSSION Tj 4 participants 10 messages Feb 16 – Feb 18

Subsystems (3)

GPIO x86 platform drivers AMD fch GPIO driver

lore

Share & tools

lore

Tj

author

2026-02-16 19:01 UTC #0 lore raw

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.

Hans de Goede

maintainer

2026-02-17 11:42 UTC #1 lore raw

Hi,

Quoted 15 lines · 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.

Quoted 7 lines

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/[email protected]/

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

Regards,

Hans

Tj

author

2026-02-17 15:25 UTC #2 lore raw

Quoted 21 lines · Hans de Goede

Quoted 20 lines · 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

Quoted 8 lines

Quoted 2 lines
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/[email protected]/
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 ([email protected]) (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

Dmitry Torokhov

2026-02-17 17:29 UTC #3 lore raw

Quoted 60 lines · Tj

Quoted 21 lines · Hans de Goede
Quoted 20 lines · 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
Quoted 8 lines
Quoted 2 lines
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/[email protected]/
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 ([email protected]) (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

Quoted 8 lines

[ 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.

Signature · 1 line

Dmitry

drivers/gpio/gpio-amd-fch.c +4 -3

index e6c6c3ec7656..9f329938202b 100644
@@ -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,

Tj

author

2026-02-17 19:35 UTC #4 lore raw

Quoted 101 lines · Dmitry Torokhov

Quoted 59 lines · Tj
Quoted 21 lines · Hans de Goede
Quoted 20 lines · 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
Quoted 8 lines
Quoted 2 lines
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/[email protected]/
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 ([email protected]) (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
Quoted 8 lines
[ 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
drivers/gpio/gpio-amd-fch.c +2 -1
index e6c6c3ec7656..9f329938202b 100644
@@ -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);
 

drivers/gpio/gpio-amd-fch.c static int amd_fch_gpio_get(struct gpio_chip *gc, · line 135

Quoted 10 lines

drivers/gpio/gpio-amd-fch.c +2 -2

  	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.

Bartosz Golaszewski

maintainer

2026-02-18 09:55 UTC #5 lore raw

In reply to Dmitry Torokhov

Quoted 71 lines · Dmitry Torokhov

Quoted 62 lines · Tj
Quoted 21 lines · Hans de Goede
Quoted 20 lines · 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
Quoted 8 lines
Quoted 2 lines
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/[email protected]/
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 ([email protected]) (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
Quoted 6 lines
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

Quoted 6 lines

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

Dmitry Torokhov

2026-02-18 17:25 UTC #6 lore raw

Quoted 82 lines · Bartosz Golaszewski

Quoted 71 lines · Dmitry Torokhov
Quoted 62 lines · Tj
Quoted 21 lines · Hans de Goede
Quoted 20 lines · 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
Quoted 8 lines
Quoted 2 lines
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/[email protected]/
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 ([email protected]) (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
Quoted 6 lines
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
Quoted 6 lines
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!

Quoted 7 lines

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.

Signature · 1 line

Dmitry

Dmitry Torokhov

2026-02-18 19:36 UTC #7 lore raw

Quoted 103 lines · Dmitry Torokhov

Quoted 82 lines · Bartosz Golaszewski
Quoted 71 lines · Dmitry Torokhov
Quoted 62 lines · Tj
Quoted 21 lines · Hans de Goede
Quoted 20 lines · 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
Quoted 8 lines
Quoted 2 lines
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/[email protected]/
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 ([email protected]) (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
Quoted 6 lines
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
Quoted 6 lines
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!
Quoted 7 lines
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:

Quoted 7 lines

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.

Signature · 1 line

Dmitry

Bartosz Golaszewski

maintainer

2026-02-18 20:21 UTC #8 lore raw

In reply to Dmitry Torokhov

Quoted 19 lines · Dmitry Torokhov

Quoted 11 lines
Quoted 8 lines
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!
Quoted 7 lines
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.

Quoted 6 lines

[+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.

Quoted 6 lines

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:

Quoted 8 lines

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

Dmitry Torokhov

2026-02-18 21:04 UTC #9 lore raw

Quoted 28 lines · Bartosz Golaszewski

Quoted 19 lines · Dmitry Torokhov
Quoted 11 lines
Quoted 8 lines
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!
Quoted 7 lines
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.
Quoted 6 lines
[+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.

Quoted 4 lines

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.

Signature · 1 line

Dmitry