Re: correctly handling EPROTO

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

On Sun, 29 Mar 2026 21:32:26 -0400, Alan Stern wrote:
> A lot of video devices use the uvcvideo driver, which (as far as I
> know) relies entirely on isochronous transfers for its streaming data.

UVC allows both isoc and bulk transport. I have one bulk device and I
found that if I randomly change urb->status to -EPROTO, the URB is not
resubmitted but (on xHCI) the endpoint keeps going, until it stops after
5 errors (no URBs left). EHCI would presumably never restart at all.

I suppose changing this might be seen as regression by some, because
the effect of each EPROTO is just a few lost frames, at least in my
very brief testing. I suppose uvcvideo could be patched to clear halt
and resubmit, if this trivial "lossy recovery" is desired.

I also got a chance to see SuperSpeed sequence mismatch thanks to other
bug (xhci_endpoint_reset() called by usb_clear_halt() may do nothing).
The effect is EPROTO, consistent with my prediction based on USB3 spec,
except that on one AMD chipset the URB never completes. Weird.

If mismatch is caused by xhci-hcd clearing only the host side (rather
than the device being cleared as in the bug above) then it seems that
resubmitting without clear halt will never fix a SuperSpeed endpoint.

Regards,
Michal