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: <CAMRc=MdWjyTyJh5zfE5qncO8ABn7QSuV1CUZXa+cSMjWoXUrNA@mail.gmail.com>
Date: Fri, 24 Oct 2025 09:20:39 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
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 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. All the information is
already in the device-tree, we just need to scan it which is what I'm
trying to do here.

Bartosz