linux-kernel - Re: [PATCH RFC 0/9] 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: <ibdmghl5dg3oda2j5ejp35ydky4xkazewhdvskm7p32vstdegr@36pj32b6dt44>
Date: Tue, 21 Oct 2025 18:23:29 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>, 
	Kees Cook <kees@...nel.org>, Mika Westerberg <westeri@...nel.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Linus Walleij <linus.walleij@...aro.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 RFC 0/9] gpio: improve support for shared GPIOs

On Tue, Oct 21, 2025 at 02:22:46PM +0200, Bartosz Golaszewski wrote:
> On Tue, Oct 21, 2025 at 2:20 PM Manivannan Sadhasivam <mani@...nel.org> wrote:
> >
> > >
> > > And with the implementation this series proposes it would mean that
> > > the perst signal will go high after the first endpoint pwrctl driver
> > > sets it to high and only go down once the last driver sets it to low.
> > > The only thing I'm not sure about is the synchronization between the
> > > endpoints - how do we wait for all of them to be powered-up before
> > > calling the last gpiod_set_value()?
> > >
> >
> > That will be handled by the pwrctrl core. Not today, but in the coming days.
> >
> 
> But is this the right approach or are you doing it this way *because*
> there's no support for enable-counted GPIOs as of yet?
> 

This is the right approach since as of today, pwrctrl core scans the bus, tries
to probe the pwrctrl driver (if one exists for the device to be scanned), powers
it ON, and deasserts the PERST#. If the device is a PCI bridge/switch, then the
devices underneath the downstream bus will only be powered ON after the further
rescan of the downstream bus. But the pwrctrl drivers for those devices might
get loaded at any time (even after the bus rescan).

This causes several issues with the PCI core as this behavior sort of emulates
the PCI hot-plug (devices showing up at random times after bus scan). If the
upstream PCI bridge/switch is not hot-plug capable, then the devices that were
showing up later will fail to enumerate due to lack of resources. The failure
is due to PCI core limiting the resources for non hot-plug PCI bridges as it
doesn't expect the devices to show up later in the downstream port.

One way to fix this issue is by making sure all the pwrctrl capable devices
underneath a PCI bridge getting probed, powered ON, and finally deasserting the
PERST# for each one of them. If the PERST# happens to be shared, it will be
deasserted once at the last. And this order has to be ensured by the pwrctrl
core irrespective of the shared PERST#.

- Mani

-- 
மணிவண்ணன் சதாசிவம்