On Mon, Sep 22, 2025 at 02:11:43AM +0300, ValdikSS wrote: > Alan, Greg, I found the reason for 1 ms delay: it is artificial, added in > v2.5.21 as a possible race condition fix: > > > /* SF interrupt might get delayed; record the frame counter value that > > * indicates when the HC isn't looking at it, so concurrent unlinks > > * behave. frame_no wraps every 2^16 msec, and changes right before > > * SF is triggered. > > */ > > ed->tick = le16_to_cpu (ohci->hcca->frame_no) + 1; > > https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/drivers/usb/host/ohci-q.c?id=9a53bdfbe26329e78f43485fc43f5fab5f27cbbc > > ED it just not getting processed at all until the time (counted by frame_no) > is reached, apparently there is/was no other way to ensure HC is finished > with this ED. > > > /* only take off EDs that the HC isn't using, accounting for > > * frame counter wraps. completion callbacks might prepend > > * EDs to the list, they'll be checked next irq. > > */ > > if (tick_before (tick, ed->tick)) { > > last = &ed->ed_rm_list; > > continue; > > } Good work tracking that down! > I removed "+ 1" and it removed that 1ms delay. Doesn't seem to break > anything in my setup. UHCI code doesn't seem to have any similar delays. > > Could it be relevant only for hardware of its era? If I add "no +1" code > quirk as a module option, disabled by default, does it sounds sane to you? I'm not sure that there is any OHCI hardware from later than that era. But regardless... Module options are frowned upon these days. Instead you could add a sysfs (or even debugfs) attribute file for controlling that "+ 1". Alan Stern
