Re: correctly handling EPROTO

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

On Thu, 19 Mar 2026 23:16:22 +0000, Thinh Nguyen wrote:
> On Wed, Mar 18, 2026, Alan Stern wrote:
> > I don't know about uas, but usb-storage handles transaction error 
> > recovery in approximately the same way.  A clear-halt is issued
> > only if the device sent a halt token -- but that's not considered a
> > transaction error.
> 
> That's -EPIPE right? With this, the storage driver knows that it
> needs to perform clear-halt because the bulk endpoint is STALL, not
> -EPROTO.

To be exact, EPIPE only means that the host got STALL handshake, but
not that the device originated it. Our good friend TT rendponds with
STALL after Bulk/Control transaction error on the downstream bus.
Similar error on Int produces a distinct ERR handshake. Don't ask me.

On IN endpoint both sides agree that the transaction didn't happen.
On OUT the device may have accepted the data (figure A-14). If you
mindlessly clear halt and resubmit it will accept same data again.

Some HCDs also report ETIME and EILSEQ, supposedly similar to EPROTO.

On xhci-hcd there is no ETIME, and EILSEQ means that the HW considers
our "transfer descriptors" ill formed. We don't bother unlocking the
endpoint, as retrying seems futile. No reports in at least two years.
Maybe other status would be more appropriate? But nobody complains.

> > Otherwise, for things like -EPROTO, usb-storage does a device reset
> > and the SCSI command is retried.  Possibly skipping some initial   
> 
> The recovery I'm thinking of doesn't involve a port reset. A port
> reset is very disruptive and will impact performance greatly. I'm
> referring to an intermediate recovery step at the usb storage driver
> without delegating to the SCSI layer.

Device reset is slow no doubt, but it may be the reason why there are
no users screaming about filesystem corruption despite the apparent
widespread neglect of TT corner cases and xhci-hcd bugs.

UAS is another can of worms, for example xHCI seems to require a
guarantee that a stream is inactive in the device (by class specific
means) before its URBs can be unlinked. See 4.6.10, 4.12.

> What I'd like to see is that the endpoint can be put in a state where
> the class driver can submit a new URB without unbind/reset/power
> cycle. With the current implementation of the xhci driver, we cannot
> do that for bulk endpoints with -EPROTO error.

It can already be done with usb_clear_halt() and this should generally
work for drivers which don't queue multiple URBs in advance (those are
subject to race conditions due to BH giveback, and to xhci-hcd bugs).

Double delivery is possible on retries after usb_clear_halt(). Probably
less likely at SuperSpeed (32 instead of 2 sequence states).

If you don't reset the pipe then xhci-hcd resets one end of it behind
your back. I could write a test patch which changes this behavior for
people to play with, but you seemed skeptical.

Alternatively, URB API would need changes to support xHCI native retry.

As you work for an xHCI IP vendor, do you know something we don't? ;)
It seems to me (and Mathias apparently too) that Reset Endpoint with
TSP followed by Set TR Dequeue would trick HW into retrying the failed
USB transaction with the data buffer of the new or resubmitted URB.

Except of course if TTs are involved. Retrying transactions involving
those is "undefined behavior" per xHCI spec. I suspect that even
ehci-hcd may not support retry by resubmission in such cases properly.

Regards,
Michal