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. Bjorn
