Re: [PATCH v4 5/7] PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Jul 02, 2025 at 08:17:44PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Jul 02, 2025 at 11:43:11AM GMT, Niklas Cassel wrote:
> > On Tue, Jul 01, 2025 at 11:38:44AM -0500, Bjorn Helgaas wrote:
> > > > 
> > > > No. The PERST# delay should be handled by the glue drivers since
> > > > they are the ones controlling the PERST# line. Doing an
> > > > unconditional wait for both the cases in DWC core, seems wrong to
> > > > me.
> > > 
> > > It ends up being a little bit weird that the delay is in the DWC core
> > > (dw_pcie_wait_for_link()) for ports that support fast links, and in
> > > the glue drivers otherwise.  It would be easier to verify and maintain
> > > if the delay were always in the DWC core.
> > > 
> > > If we had a dw_pcie_host_ops callback for PERST# deassertion, the
> > > delay could be in the DWC core, but I don't know if there's enough
> > > consistency across drivers for that to be practical.
> > 
> > Currently, there is not much consistency between the glue drivers,
> > so adding a DWC core API to assert/deassert PERST# sounds like a
> > good idea to me. The callback could even be supplied a struct
> > gpio_desc pointer.
> 
> +1 for consolidating the PERST# handling. But just FYI, I'm going to
> move the PERST# deassert handling from controller drivers to pwrctrl
> drivers as once pwrctrl drivers are used to control the power
> supplies, they should control PERST# as well. Currently, this is the
> missing piece for pwrctrl framework.
> 
> Also, we cannot entirely get rid of the PERST# handling in
> controller drivers, since they need to assert PERST# before
> resetting the RC during init.

I thought pwrctrl was optional.  The PERST# management is not
optional, is it?

Bjorn