X86 platform drivers
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Bartosz Golaszewski <brgl@kernel.org>,
	 Linus Walleij <linusw@kernel.org>
Cc: Tj <tj.iam.tj@proton.me>, Hans de Goede <hansg@kernel.org>,
	 metux IT consult <info@metux.net>,
	platform-driver-x86@vger.kernel.org
Subject: Re: pcengines_apuv2: LEDs/Input fails since v6.18
Date: Wed, 18 Feb 2026 11:36:20 -0800	[thread overview]
Message-ID: <aZYUj0dUL5bZtwSF@google.com> (raw)
In-Reply-To: <aZX0EynAKvqXWzq2@google.com>

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

  reply	other threads:[~2026-02-18 19:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2026-02-18 20:21           ` Bartosz Golaszewski
2026-02-18 21:04             ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZYUj0dUL5bZtwSF@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=brgl@kernel.org \
    --cc=hansg@kernel.org \
    --cc=info@metux.net \
    --cc=linusw@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tj.iam.tj@proton.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox