On Thu, Mar 23, 2023 at 11:41:43AM +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? > > Yes, this is correct. The reason why "fast links" is that we use the active link reporting (as it is available on such ports) to figure out whether the link trained or not and if not we come out early because it is likely that the device is not there anymore. When the link has been trained we know that the device is still there so can wait for longer it to reply. For the "slow links" this cannot be done so wait for 1s to avoid long waits if the device is already gone. I'm not entirely sure if this is fine for the reset path. I think it is but I hope Lukas/others correct me if not.
