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
