Re: [PATCH] PCI/PM: Wait longer after reset when active link reporting is supported

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Mon, Mar 27, 2023 at 09:40:50AM -0500, Bjorn Helgaas wrote:
> On Mon, Mar 27, 2023 at 12:42:50PM +0300, Mika Westerberg wrote:
> > On Sun, Mar 26, 2023 at 08:22:07AM +0200, Lukas Wunner wrote:
> > > On Wed, Mar 22, 2023 at 05:16:24PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Mar 21, 2023 at 11:50:31AM +0200, Mika Westerberg wrote:
> 
> > > > After ac91e6980563, we called pci_bridge_wait_for_secondary_bus() with
> > > > timeouts of either:
> > > > 
> > > >   60s for reset (pci_bridge_secondary_bus_reset() or
> > > >       dpc_reset_link()), or
> > > > 
> > > >    1s for resume (pci_pm_resume_noirq() or pci_pm_runtime_resume() via
> > > >       pci_pm_bridge_power_up_actions())
> > > > 
> > > > If I'm reading this right, the main changes of this patch are:
> > > > 
> > > >   - For slow links (<= 5 GT/s), we sleep 100ms, then previously waited
> > > >     up to 1s (resume) or 60s (reset) for the device to be ready.  Now
> > > >     we will wait a max of 1s for both resume and reset.
> > > > 
> > > >   - For fast links (> 5 GT/s) we wait up to 100ms for the link to come
> > > >     up and fail if it does not.  If the link did come up in 100ms, we
> > > >     previously waited up to 1s (resume) or 60s (reset).  Now we will
> > > >     wait up to 60s for both resume and reset.
> > > > 
> > > > So this *reduces* the time we wait for slow links after reset, and
> > > > *increases* the time for fast links after resume.  Right?
> > > 
> > > Good point.  So now the wait duration hinges on the link speed
> > > rather than reset versus resume.
> > > ...
> 
> > I can update the patch accordingly.
> 
> If you do an update, is it possible to split into two patches so one
> increases the time for resume for fast links and the other decreases
> the time for reset on slow links?  I'm thinking about potential debug
> efforts where it might be easier to untangle things if they are
> separate.

Yes, sure.