Re: correctly handling EPROTO

[Michal Pecio <michal.pecio@gmail.com>]

On Sat, 28 Mar 2026 21:52:37 -0400, Alan Stern wrote:
> Storage is not a good example.  It's so obviously critical that a
> huge amount of effort has gone into making it exceptionally robust.
> Very few of the other drivers do as good a job of error recovery.

I though it's a good example because all the effort is in vain if
xhci runs subsequent URBs before the driver even knows about it.

> Other drivers that might be affected include things like HID

HID doesn't submit multiple URBs so there is nothing to restart after
an error, but it's affected by the unilateral toggle reset issue.

And by the way, is there any chance that ohci-hcd also clears host
toggle on errors? I'm doing simple test with a keyboard (low speed
interrupt in): disconnect D+ which causes some ETIME errors, connect
it back, press and hold 'u'. Half the time uuuuu shows up, half the
time only when I later add shift does UUUUU show up. Looks like the
first packet is dropped due to toggle. I see it on xhci (known bug)
and also on ohci, but never on ehci with a TT hub.

> various serial protocols

If you mean usbserial, they are pretty boring. On completion they just
submit the next URB, except for EPIPE, ENODEV etc. There is data loss
on OUT endpoints, there can be more data loss due to toggle mismatch,
and throwing out already queued URBs would probably add more loss.

It seems usbserial won't care whether we restart instantly or not.

> network drivers, video & audio

And I suspect they are similar, because higher layers can tolerate loss
so why bother recovering from USB errors. I may play with them later.

BTW, I think audio only runs over isochronous. But I should have a bulk
video device somethere.

Regards,
Michal