On Mon, Oct 06, 2025 at 06:10:59PM +0200, Bartosz Golaszewski wrote: > On Mon, Oct 6, 2025 at 5:43 PM Manivannan Sadhasivam <[email protected]> wrote: > > > > On Wed, Sep 24, 2025 at 11:25:12AM -0700, Dmitry Torokhov wrote: > > > Hi Bartosz, > > > > > > > > > > > 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 -- மணிவண்ணன் சதாசிவம்
