Re: correctly handling EPROTO

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Wed, Mar 18, 2026, Michal Pecio wrote:
> On Wed, 18 Mar 2026 13:46:26 -0400, Alan Stern wrote:
> > On Wed, Mar 18, 2026 at 10:54:20AM +0100, Oliver Neukum wrote:
> > > On 17.03.26 19:03, Alan Stern wrote:
> > > > You know, with a USB-2 host controller, transaction errors don't
> > > > make an endpoint unusable, and clear-halt isn't necessary.
> 
> Depends on what you mean by "usable". If you get EPROTO reading from
> a Transaction Translator and the TT discards the packet (because of
> timeout on Int or by explicit SW request on Bulk) then not only is the
> particular packet lost because the device got its ACK and moved on, but
> I suspect the next packet will be dropped too due to toggle mismatch.
> 
> Granted, EPROTO outside of disconnections is apparently rare enough
> that a horde of users demanging this to be fixed hasn't materialized.

I've seen Windows drivers handling UAS transaction error recovery
through clear-halt and retry SCSI command, and it works well. I hope to
see this type of recovery implemented for usb storage and uas devices in
the future.

> 
> I found simple ways to produce recoverable EPROTO at low/full speed,
> but no such luck with higher speeds so far. It would be helpful.

Get a bad cable, that should help triggering transaction errors. Back
when I was doing more hardware testing, we were able to trigger this
more easily when testing BOT and UAS devices behind certain hubs and
docks.

> 
> > > > I wonder if xhci-hcd couldn't be adjusted to behave the same way
> > > > (issuing its own clear-halt internally, if that is needed). That
> > > > would make things simpler.
> > > 
> > > It could be. But do you want a HCD to generate requests to endpoint
> > > 0 on its own without coordination with usbcore or drivers bound to
> > > interfaces of the device?
> 
> I believe the intent is to maintain the illusion that drivers can just
> resubmit the failed URB and have that become a proper retry.
> 
> It likely could be done, but it's still not the same thing as old HCDs
> are doing because it opens the possibility of double delivery, while
> closing the possibility of further packet loss speculated about above.
> 
> Question is if this illusion is worth fighting for, when
> 1. it hasn't been 100% reliable since at least USB 2.0 and TTs
> 2. USB-IF keeps creating problems for software trying to be like that
> 3. xhci-hcd has been this mess for 15 years without loud complaints
> 
> What should an HCD do if such request fails? Just refuse URBs?
> 
> > Michal should be the person to answer these questions.  I guess that
> > a clear-halt is necessary for synchronizing an xHCI host controller
> > with the device's endpoint after an error, but I don't really know.
> > Maybe it's necessary only for USB-3 devices?
> 
> Strictly, it's the opposite - synchronize the device with the host
> having already zeroed its toggle or SuperSpeed sequence number.
> 
> Such toggle mismatch at USB2 speeds results in loss of next packet.
> 
> AFAIU, SuperSpeed sequence mismatch is covered by USB3 8.11, which says
> "discard with no response", so maybe we would keep getting EPROTO due
> to timeouts while wrong number is being retried, but not sure.
> 
> Resetting host sequence state is not mandatory, but the alternative is
> intended for retrying the same URB, not another identical one. That
> would be an edge case possibly exercised by no SW other than Linux.
> 

The retrying of the URB or sending a new set of URBs should be a
decision by the class driver where synchronization at the higher
protocol may be needed. An URB failed with -EPROTO may mean some
previous successful transfers need to be discarded and retried also.

What we do know is that an -EPROTO means that the xhci endpoint state
was halted, the xhci would need to reset (not soft retry) the endpoint
before it can be used again. Since the bulk sequence is reset from reset
ep command, we'd need clear-halt to synchronize with the device side.
The reset ep command behavior (and when to use it) is xhci specific, so
IMHO, it should the xhci driver to handle the clear-halt. Which URB(s)
need to be retried should be a decision by the upperlayer drivers.

BR,
Thinh