Message-Id: <DFJAFK3DTBOZ.3G2P3A5IH34GF@kernel.org>
Date: Thu, 08 Jan 2026 15:46:36 +0100
From: "Michael Walle" <mwalle@...nel.org>
To: "Bartosz Golaszewski" <brgl@...ev.pl>, "Kees Cook" <kees@...nel.org>,
 "Mika Westerberg" <westeri@...nel.org>, "Dmitry Torokhov"
 <dmitry.torokhov@...il.com>, "Andrew Morton" <akpm@...ux-foundation.org>,
 "Linus Walleij" <linus.walleij@...aro.org>, "Manivannan Sadhasivam"
 <mani@...nel.org>, "Rob Herring" <robh@...nel.org>, "Krzysztof Kozlowski"
 <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>, "Saravana
 Kannan" <saravanak@...gle.com>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, "Andy Shevchenko" <andy@...nel.org>, "Catalin
 Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 "Srinivas Kandagatla" <srini@...nel.org>, "Liam Girdwood"
 <lgirdwood@...il.com>, "Mark Brown" <broonie@...nel.org>, "Jaroslav Kysela"
 <perex@...ex.cz>, "Takashi Iwai" <tiwai@...e.com>, "Alexey Klimov"
 <alexey.klimov@...aro.org>, "Bjorn Andersson" <andersson@...nel.org>,
 "Konrad Dybcio" <konradybcio@...nel.org>
Cc: <linux-hardening@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-gpio@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
 <linux-sound@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>, "Bartosz
 Golaszewski" <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs

Hi Bartosz,

On Wed Nov 12, 2025 at 2:55 PM CET, Bartosz Golaszewski wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> Problem statement: GPIOs are implemented as a strictly exclusive
> resource in the kernel but there are lots of platforms on which single
> pin is shared by multiple devices which don't communicate so need some
> way of properly sharing access to a GPIO. What we have now is the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> doesn't do any locking or arbitration of access - it literally just hand
> the same GPIO descriptor to all interested users.
>
> The proposed solution is composed of three major parts: the high-level,
> shared GPIO proxy driver that arbitrates access to the shared pin and
> exposes a regular GPIO chip interface to consumers, a low-level shared
> GPIOLIB module that scans firmware nodes and creates auxiliary devices
> that attach to the proxy driver and finally a set of core GPIOLIB
> changes that plug the former into the GPIO lookup path.
>
> The changes are implemented in a way that allows to seamlessly compile
> out any code related to sharing GPIOs for systems that don't need it.

The problem here is that the aarch64 defconfig has ARCH_QCOM enabled
and thus it will get enabled for any platforms, right?

I haven't grokked everything, but does GPIO_SHARED=y makes any sense
without GPIO_SHARED_PROXY? It seems to me that the probing of shared
pins will be deferred indefinitely.

> The practical use-case for this are the powerdown GPIOs shared by
> speakers on Qualcomm db845c platform, however I have also extensively
> tested it using gpio-virtuser on arm64 qemu with various DT
> configurations.
>
> I'm Cc'ing some people that may help with reviewing/be interested in
> this: OF maintainers (because the main target are OF systems initially),
> Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> in audio or regulator drivers and one of the goals of this series is
> dropping the hand-crafted GPIO enable counting via struct
> regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> to also cover ACPI (even though I don't know about any ACPI platform that
> would need this at the moment, I think it makes sense to make the
> solution complete), Dmitry (same thing but for software nodes), Mani
> (because you have a somewhat related use-case for the PERST# signal and
> I'd like to hear your input on whether this is something you can use or
> maybe it needs a separate, implicit gpio-perst driver similar to what
> Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> last week in person and I also use the auxiliary bus for the proxy
> devices).

This broke my board (using the arm64 defconfig, works without
GPIO_SHARED of course). I'm seeing two issues here with my board
(arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67*):

 (1) It's GPIO controller (gpio-davinci) doesn't support
     .get_direction so I'm getting ENOTSUPP during probing of the
     (some?) shared GPIOs. 
     
 (2) GPIO_SHARED_PROXY is default m in the defconfig, but I need the
     pins for the root filesystem medium, i.e. the SD card regulators.

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)

Powered by blists - more mailing lists