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

[Niklas Cassel <cassel@kernel.org>]

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.


Kind regards,
Niklas