Re: [PATCH v2 00/10] gpio: improve support for shared GPIOs

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 24/10/2025 10:20, Bartosz Golaszewski wrote:
> On Fri, Oct 24, 2025 at 9:17 AM Péter Ujfalusi
> <peter.ujfalusi@linux.intel.com> wrote:
>>
>>
>>
>> On 22/10/2025 16:10, Bartosz Golaszewski wrote:
>>> 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.
>>
>> I had few stabs on this in the past, all got somehow derailed, one
>> example was:
>> https://lkml.org/lkml/2019/10/30/311
>>
> 
> The main issue I see with this approach is adding an actual device
> node for the shared GPIO which is now not accepted in DT bindings. We
> only create nodes for actual HW components.

Right, that policy came later, true.

All the information is
> already in the device-tree, we just need to scan it which is what I'm
> trying to do here.

I had a prototype later without the sofware-node which worked for the
use case I had, but over the years I dropped it, it was a bit of hassle
to roll it for nothing.

One can argue that the shared-gpio node is describing the solder blob
where the GPIO line is split and routed to two different component.
With the approach one can handle cases where the level is inverted by a
passive component for one of the device for example - unfortunately I
have seen such a board marvel as well.

The device's binding will tell _how_ it expects the GPIO's active level,
which might or might not match with the real level of the GPIO line and
if one of the device's branch have an inverter, that is going to be
interesting to work out in conjunction with the other devices non
inverted 'direct' line to the same GPIO.

Never the less, it is great that someone is trying to get this supported!

> 
> Bartosz

-- 
Péter