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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3907f4ea-31c2-42fb-b4ff-a6952874a9bb@linux.intel.com>
Date: Fri, 24 Oct 2025 10:32:25 +0300
From: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: 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>, 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 v2 00/10] gpio: improve support for shared GPIOs



On 24/10/2025 10:20, Bartosz Golaszewski wrote:
> On Fri, Oct 24, 2025 at 9:17 AM Péter Ujfalusi
> <peter.ujfalusi@...ux.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