Re: correctly handling EPROTO

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

On Thu, 12 Mar 2026 16:57:18 +0100, Oliver Neukum wrote:
> On 12.03.26 15:21, Alan Stern wrote:
>   
> > There's a discussion about the same issue here:
> > 
> > 	https://bugzilla.kernel.org/show_bug.cgi?id=221184
> > 
> > See especially the later parts, starting with comment #28.  
> 
> Well, that is fascinating, but not necessarily in a comfortable
> way. It seems to me that for all drivers to care about the
> exact details of getting which toggle back into sync is not
> a viable strategy. This I'd say, when in doubt, clear a halt.

The official USB philosophy appears to be:
- remove any remaining URBs from the endpoint
- clear halt (even if not halted)
- use class control requests to bring the HW and SW to a valid state
- submit new URBs

Some thoughts:

1. Giving up on EPROTO may be overly pessimistic. Bit flips happen.

   But EPROTO may also mean disconnection. Parent hub should notice,
   then disconnect() will be called at some point and usb_submit_urb()
   will begin returning ENODEV.

   Some cable failures cause persistent EPROTO without disconnection
   being detected, e.g. D+ or D- discontinuity at low or full speed.

2. The idea that a driver can retry a transfer by resubmitting the
   failed URB encounters certain problems.

 a Resubmitting a multi-packet URB is tricky - part of it may have
   already been transferred, so the URB may need to be modified.

 b With transaction translators (LS/FS behind a HS hub) one IN packet
   may already be lost forever when you see the first EPROTO. The
   interrupt case seems impossible to fix due to HW timings. Fixing the
   bulk case would take actions different than ordinary URB submission.
   No API nor EHCI support seems to exist, xHCI can't do it at all.

   Note: even a high-speed capable device may sometimes work like that.

 c If you usb_clear_halt() before resubmitting, a previously delivered
   packet may be resent and accepted again (if its ACK was lost). Both
   IN and OUT seem potentially affected. Some classe may not care.

3. EHCI/OHCI/UHCI can do proper retries, except case 2b, simply by
   resubmitting while minding points 2a and 2c (so no clear halt).

   The same action on xHCI currently results in 50% chance of the next
   packet being dropped by HW and the URB waiting for another packet.

   Tricking xHCI to behave like EHCI is uncharted territory. It seems
   to stray away from offical USB recommendations.

4. xHCI can support retries cleanly and painlessly (except for the
   impossible case of TT) if the URB isn't given back or is given back
   with the understanding that it is still present in the HW queue and
   can only be unlinked or resumed at the point it got stuck. Issues:

 a No API exists for either option. However, a few retries are already
   made before completing with EPROTO status (except for TT).

 b This doesn't work 100% right and is disabled on some controllers.

5. If you have more URBs queued in advance, you may encounter bugs due
   to race conditions (or outright broken logic in case of xHCI).


Summary:

Retrying may or may not be productive - see 1.

Drivers written for EHCI encounter problems on xHCI - see 3.

Existing API is awkward/insufficient for retries - see 2a and 4.

In certain cases retries are impossible anyway - see 2b and 4b.
Extra work by class specific means is inevitable. See "USB philosophy".

Regards,
Michal