On Mon, Sep 22, 2025 at 05:38:38PM +0300, ValdikSS wrote: > On 22.09.2025 5:16 PM, Alan Stern wrote: > > 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: > > > > 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". > > I just implemented another approach: do not unlink the ED right away, > instead mark it IDLE and unlink only if no consecutive transfers are > performed after the timeout. This still preserves one-frame delay while > unlinking, should be safe. That does indeed sound like a better approach. > Please take a look if you have free time. Feel free to post your patch on the mailing list for review. > I'm no kernel developer by any > means :) Seems like you're becoming one, like it or not! Welcome to the community. Alan Stern
