On Mon, Oct 06, 2025 at 06:10:59PM +0200, Bartosz Golaszewski wrote:

On Mon, Oct 6, 2025 at 5:43 PM Manivannan Sadhasivam [off-list ref] wrote:

quoted

On Wed, Sep 24, 2025 at 11:25:12AM -0700, Dmitry Torokhov wrote:

quoted

Hi Bartosz,

quoted

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.

How is this different from the existing gpio-backed regulator/supply?
IMO GPIOs are naturally exclusive-use resources (in cases when you need
to control them, not simply read their state), and when there is a need
to share them there are more appropriate abstractions that are built on
top of GPIOs...

Not always... For something like shared reset line, consumers request the line
as GPIO and expect gpiolib to do resource manangement.

They could use the reset API and it would implicitly create a virtual
device that requests the reset GPIO and controls its enable count.
Except that some devices also do a specific reset sequence with delays
etc. That would require some additional logic in reset-gpio.

I was referring to the PCIe PERST# line, for which the 'reset-gpios' property
already exist in the schema. Now, you want me to model this simple GPIO as a
fake reset controller and use it the PCIe Bridge nodes through 'resets'
property?

- Mani

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