On Thu, Jun 05, 2025 at 02:28:41PM +0200, Niklas Cassel wrote: > On Wed, Jun 04, 2025 at 01:44:45PM -0500, Bjorn Helgaas wrote: > > On Wed, Jun 04, 2025 at 10:40:09PM +0530, Manivannan Sadhasivam wrote: > > > > > > If we add a 100 ms sleep after wait_for_link(), then I suggest that we > > > > also reduce LINK_WAIT_SLEEP_MS to something shorter. > > > > > > No. The 900ms sleep is to make sure that we wait 1s before erroring out > > > assuming that the device is not present. This is mandated by the spec. So > > > irrespective of the delay we add *after* link up, we should try to detect the > > > link up for ~1s. > > > > I think it would be sensible for dw_pcie_wait_for_link() to check for > > link up more frequently, i.e., reduce LINK_WAIT_SLEEP_MS and increase > > LINK_WAIT_MAX_RETRIES. > > > > If LINK_WAIT_SLEEP_MS * LINK_WAIT_MAX_RETRIES is for the 1.0s > > mentioned in sec 6.6.1, seems like maybe we should make a generic > > #define for it so we could include the spec reference and use it > > across all drivers. And resolve the question of 900ms vs 1000ms. > > Like Bjorn mentioned, when I wrote reduce LINK_WAIT_SLEEP_MS, > I simply meant that we should poll for link up more frequently. > > But yes, if we reduce LINK_WAIT_SLEEP_MS we should bump > LINK_WAIT_MAX_RETRIES to not change the current max wait time. > > > Bjorn, should I send something out after -rc1, or did you want > to work on this yourself? Yes, please post something after -rc1. Given the number of drivers and the much smaller number of msleep() calls, I suspect lots of drivers have similar problems. Bjorn
