On Mon, May 23, 2022 at 10:20 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Sun, May 22, 2022 at 01:37:50AM +0800, Sheng Bi wrote: > > On Sat, May 21, 2022 at 8:49 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > > On Sat, May 21, 2022 at 04:36:10PM +0800, Sheng Bi wrote: > > > > If so, I also want to align the polling things mentioned in the > > > > question from Alex, since pci_dev_wait() is also used for reset > > > > functions other than SBR. To Bjorn, Alex, Lucas, how do you think if > > > > we need to change the polling in pci_dev_wait() to 20ms intervals, or > > > > keep binary exponential back-off with probable unexpected extra > > > > timeout delay. > > > > > > The exponential backoff should probably be capped at some point > > > to avoid excessive wait delays. I guess the rationale for > > > exponential backoff is to not poll too frequently. > > > Capping at 20 msec or 100 msec may be reasonable, i.e.: > > > > > > - delay *= 2; > > > + delay = min(delay * 2, 100); > > > > Capping at 20 or 100 msec seems reasonable to me. Btw, since 20 msec > > is not a long time in these scenarios, how about changing to a fixed > > 20 msec interval? > > The callers of pci_dev_wait() seem to wait for the spec-defined > delay and only call pci_dev_wait() to allow for an additional period > that non-compliant devices may need. That extra delay can be expected > to be low, which is why it makes sense to start with a short poll interval > and gradually extend it. So the algorithm seems to be reasonable and > I wouldn't recommend changing it to a constant interval unless that > fixes something which is currently broken. > > Thanks, > > Lukas Thanks Lukas! >From my perspective, there is nothing broken so far, but a theoretical unexpected extra delay while the timeout has passed. So I will keep pci_dev_wait() as previously with exponential backoff in this patch, and change the pci_bridge_secondary_bus_wait() with "jiffies" and pci_dev_wait(). Thanks, windy
