Re: correctly handling EPROTO

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

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 found simple ways to produce recoverable EPROTO at low/full speed,
but no such luck with higher speeds so far. It would be helpful.

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

Regards,
Michal