Re: correctly handling EPROTO

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

On Wed, Mar 18, 2026, Alan Stern wrote:
> On Wed, Mar 18, 2026 at 11:59:21PM +0000, Thinh Nguyen wrote:
> > 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 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 

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.

> error.  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.

Currently we _have_ to do a port reset because the bulk sequence can be
out of sync and the xhci doesn't synchronize against the device for the
storage driver to retry the command directly.

> portion of the data if the transfer was partially successful.  (This 
> might not work very well for things like tape drives, but disk drives 
> have the convenient feature that reads and writes are idempotent.)
> 
> > 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.
> 
> That's a good point.  There's only so much we can expect the core to 
> handle.

Right. Not sure what the core can do here.

> 
> > 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.
> 
> And for which drivers will we want to go to the trouble of adding this 
> kind of error recovery?  Alternatives include doing just enough to make 
> the endpoint start working again and ignoring any data loss, or 
> declaring the whole device to be offline (which would need at least an 
> unbind and maybe even a power cycle to recover from).
> 

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.

BR,
Thinh