On Tue, Nov 18, 2025 at 12:16 PM Geert Uytterhoeven <[email protected]> wrote: > > Hi Bartosz, > > On Wed, 12 Nov 2025 at 15:05, Bartosz Golaszewski <[email protected]> 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 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. > > Thanks for your series, part of which is now present linux-next. > IIUIC, this requires the direction of the GPIO to be fixed? > > We have a long-standing use-case on various Renesas R-Car Gen3 boards > (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and > key switches. Basically, the GPIO is connected to: > 1. A key switch connecting to GND when closed, with pull-up. > 2. The gate of an N-channel MOSFET, turning on an LED when driven > high. > > Hence: > - In output mode, the LED can be controlled freely, > - In input mode, the LED is on, unless the key is pressed, > - Hence the switch state can only be read when the LED is turned on. > If you have any idea how to handle this, feel free to reply ;-) > > Thanks! >
How is this done currently? Even without this series and using the GPIOD_FLAGS_BIT_NONEXCLUSIVE, the descriptor has a well-defined direction so it's not possible for two drivers to request it as input and output simultaneously. The second requester will override the previous settings. Bart
