Re: correctly handling EPROTO

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

On Wed, 18 Mar 2026 21:56:27 -0400, Alan Stern wrote:
> On Wed, Mar 18, 2026 at 10:38:51PM +0100, Michal Pecio wrote:
> > 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.  
>
> (Is it the TT that keeps track of the toggle state, or the host 
> controller?  I don't remember and I'm too lazy to look up the answer.)

Good question. I skimmed USB2 chapters about TT (11.14+) and haven't
seen this spelled out clearly. However,
- I don't remember ever reading about a requirement for TT to keep
  separate toggle state upstream and downstream
- there is nothing about what CSPLIT response to send after device IN
  packet was discarded due to wrong toggle
- we would need a separate request to clear TT toggle when we clear
  host and device toggle, no such request seems to exist

So I still suspect that TT is just a dumb forwarder and that we get
toggle mismatch when a packet is lost on the HS bus, which sets us up
to lose the next valid packet too.

> By "unusable", I meant that no more data could be transmitted through 
> that endpoint until some sort of recovery action had been carried out 
> (such as clear-halt, set-config, or device reset).
>
> Yes, data loss is sometimes inevitable, and we shouldn't worry too
> much about things we can't prevent.

But an EP which loses data is not as usable as we might wish for.
Doing usb_clear_halt() prevents at least that second loss, which may
occur in far future when we think the error has been solved already.

USB-IF doesn't seem to consider "pipes" a reliable transport and
expects class drivers to anticipate data loss and work around it.

HID, for example, appears to provide a mandatory control request to
poll for the current state of input controls. This could recover lost
data (except from mice) after resetting the pipe to avoid more loss.
 
> The major example showed up just a few weeks ago.  It was an old
> system where some component (the PCI bus?) apparently could become
> saturated at high load, leading to communication failures because the
> host controller couldn't access the data needed to keep up with its
> scheduled work.

I'm aware of this bug and it's an odd one, because I don't understand
why reducing retry delay seems to help.

> Just to be clear, are you saying there's no way for an xHC to restart
> a (host-side) halted non-SuperSpeed endpoint without setting the
> toggle back to 0?

To be clear, I'm saying that most xHCI people probably think so. You
have seen Thinh's reaction to my suggestion that we could do otherwise.

We need a Reset Endpoint command (xHCI 4.6.8) to clear the Halted flag
in xHC, otherwise it will refuse to run the endpoint to protect us from
race conditions (new submission while the error is being reported).

Clearing toggle/sequesce state is optional. If we don't clear it then
"the endpoint shall continue execution by retrying the last transaction
[after restart] if no other commands have been issued to the endpoint."

We can command it to move to the next URB (possibly not submitted yet)
and only then restart the endpoint. But this is another weird thing
that Linux does, possibly noboddy else does it, USB-IF doesn't expect
us to do it, and HW vendors may not test this edge case.

It's something that would have made sense to try 15 years ago, but
today I think you may meet resistance. Ask Mathias what he thinks.

Regards,
Michal