On Mon, Sep 22, 2025 at 05:38:38PM +0300, ValdikSS wrote:

On 22.09.2025 5:16 PM, Alan Stern wrote:

quoted

On Mon, Sep 22, 2025 at 02:11:43AM +0300, ValdikSS wrote:

quoted

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!

quoted

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