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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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