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.
