* pcengines_apuv2: LEDs/Input fails since v6.18 @ 2026-02-16 19:01 Tj 2026-02-17 11:42 ` Hans de Goede 0 siblings, 1 reply; 10+ messages in thread From: Tj @ 2026-02-16 19:01 UTC (permalink / raw) To: Dmitry Torokhov, metux IT consult", platform-driver-x86; +Cc: Hans de Goede 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-16 19:01 pcengines_apuv2: LEDs/Input fails since v6.18 Tj @ 2026-02-17 11:42 ` Hans de Goede 2026-02-17 15:25 ` Tj 0 siblings, 1 reply; 10+ messages in thread From: Hans de Goede @ 2026-02-17 11:42 UTC (permalink / raw) To: Tj, Dmitry Torokhov, metux IT consult", platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-17 11:42 ` Hans de Goede @ 2026-02-17 15:25 ` Tj 2026-02-17 17:29 ` Dmitry Torokhov 0 siblings, 1 reply; 10+ messages in thread From: Tj @ 2026-02-17 15:25 UTC (permalink / raw) To: Hans de Goede, Dmitry Torokhov, metux IT consult", platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-17 15:25 ` Tj @ 2026-02-17 17:29 ` Dmitry Torokhov 2026-02-17 19:34 ` Tj 2026-02-18 9:55 ` Bartosz Golaszewski 0 siblings, 2 replies; 10+ messages in thread From: Dmitry Torokhov @ 2026-02-17 17:29 UTC (permalink / raw) To: Tj Cc: Hans de Goede, metux IT consult", platform-driver-x86, Bartosz Golaszewski 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, ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-17 17:29 ` Dmitry Torokhov @ 2026-02-17 19:34 ` Tj 2026-02-18 9:55 ` Bartosz Golaszewski 1 sibling, 0 replies; 10+ messages in thread From: Tj @ 2026-02-17 19:34 UTC (permalink / raw) To: Dmitry Torokhov Cc: Hans de Goede, metux IT consult", platform-driver-x86, Bartosz Golaszewski 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-17 17:29 ` Dmitry Torokhov 2026-02-17 19:34 ` Tj @ 2026-02-18 9:55 ` Bartosz Golaszewski 2026-02-18 17:25 ` Dmitry Torokhov 1 sibling, 1 reply; 10+ messages in thread From: Bartosz Golaszewski @ 2026-02-18 9:55 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Tj, Hans de Goede, metux IT consult, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-18 9:55 ` Bartosz Golaszewski @ 2026-02-18 17:25 ` Dmitry Torokhov 2026-02-18 19:36 ` Dmitry Torokhov 2026-02-18 20:21 ` Bartosz Golaszewski 0 siblings, 2 replies; 10+ messages in thread From: Dmitry Torokhov @ 2026-02-18 17:25 UTC (permalink / raw) To: Bartosz Golaszewski, Linus Walleij Cc: Tj, Hans de Goede, metux IT consult, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-18 17:25 ` Dmitry Torokhov @ 2026-02-18 19:36 ` Dmitry Torokhov 2026-02-18 20:21 ` Bartosz Golaszewski 1 sibling, 0 replies; 10+ messages in thread From: Dmitry Torokhov @ 2026-02-18 19:36 UTC (permalink / raw) To: Bartosz Golaszewski, Linus Walleij Cc: Tj, Hans de Goede, metux IT consult, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-18 17:25 ` Dmitry Torokhov 2026-02-18 19:36 ` Dmitry Torokhov @ 2026-02-18 20:21 ` Bartosz Golaszewski 2026-02-18 21:04 ` Dmitry Torokhov 1 sibling, 1 reply; 10+ messages in thread From: Bartosz Golaszewski @ 2026-02-18 20:21 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Walleij, Tj, Hans de Goede, metux IT consult, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pcengines_apuv2: LEDs/Input fails since v6.18 2026-02-18 20:21 ` Bartosz Golaszewski @ 2026-02-18 21:04 ` Dmitry Torokhov 0 siblings, 0 replies; 10+ messages in thread From: Dmitry Torokhov @ 2026-02-18 21:04 UTC (permalink / raw) To: Bartosz Golaszewski Cc: Linus Walleij, Tj, Hans de Goede, metux IT consult, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-02-18 21:04 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-02-16 19:01 pcengines_apuv2: LEDs/Input fails since v6.18 Tj 2026-02-17 11:42 ` Hans de Goede 2026-02-17 15:25 ` Tj 2026-02-17 17:29 ` Dmitry Torokhov 2026-02-17 19:34 ` Tj 2026-02-18 9:55 ` Bartosz Golaszewski 2026-02-18 17:25 ` Dmitry Torokhov 2026-02-18 19:36 ` Dmitry Torokhov 2026-02-18 20:21 ` Bartosz Golaszewski 2026-02-18 21:04 ` Dmitry Torokhov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.