Re: [PATCH v4 0/8] PCI/pwrctrl: Major rework to integrate pwrctrl devices with controller drivers

[Manivannan Sadhasivam]

On Fri, Jan 16, 2026 at 02:40:36PM +0100, Niklas Cassel wrote:
> On Fri, Jan 16, 2026 at 11:54:26AM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Jan 15, 2026 at 02:26:32PM -0500, Sean Anderson wrote:
> > > > 
> > > > Not at all. We cannot model PERST# as a GPIO in all the cases. Some drivers
> > > > implement PERST# as a set of MMIO operations in the Root Complex MMIO space and
> > > > that space belongs to the controller driver.
> > > 
> > > That's what I mean. Implement a GPIO driver with one GPIO and perform
> > > the MMIO operations as requested.
> > > 
> > > Or we can invert things and add a reset op to pci_ops. If present then
> > > call it, and if absent use the PERST GPIO on the bridge.
> > > 
> > 
> > Having a callback for controlling the PERST# will work for the addressing the
> > PERST# issue, but it won't solve the PCIe switch issue we were talking above.
> > And this API design will fix both the problems.
> > 
> > But even in this callback design, you need to have modifications in the existing
> > controller drivers to integrate pwrctrl. So how that is different from calling
> > just two (or one unified API for create/power_on)?
> 
> FWIW, I do think that it is a good idea to create a reset op to pci_ops
> that will implement PERST# assertion/deassertion.
> 
> Right now, it is a mess, with various drivers doing this at various
> different places.
> 
> Having a specific callback, the driver implement it however they want
> GPIO, MMIO, whatever, and it could even be called by (in case of DWC,
> the host_init, by pwrctrl, or potentially by the PCI core itself before
> enumerating the bus.
> 
> If we don't do something about it now, the problem will just get worse
> with time. Yes, it will take time before all drivers have migrated and
> been tested to have a dedicated PERST# reset op, but for the long term
> maintainability, I think it is something that we should do.
> 
> I also know that some drivers have some loops with retry logic, where
> they might go down in link speed, but right now I don't see why those
> drivers shouldn't be able to keep that retry logic just because we
> add a dedicated PERST# callback.
> 
> 
> All that said, that would be a separate endeavor and can be implemented
> later.
> 

[looks like my previous reply was lost, so resending it]

Agree. Having unification always helps!

- Mani

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