Re: correctly handling EPROTO

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

On Sat, 21 Mar 2026 02:14:46 +0000, Thinh Nguyen wrote:
> Windows has a clever way to handle this for UAS. It sends a
> command/task with the same tag as the failing transfer on the command
> endpoint, triggering an overlap tag response and causing the device
> side to cancel the command along with the pending data transfer. This
> puts the host and device in sync again.
> 
> All compliant UAS devices must support overlap tag detection.

Doing what Windows does may be a good idea. I have seen certain UAS
bridges cause problems on multiple xHCI controllers when data URBs are
unlinked after receiving an error status. I suspect those chips may
violate USB3 spec with current UAS driver, but I have no way to debug.

> The clear-halt doesn't have to be done after the unlinking of URBs.
> The xhci endpoint is in stopped state after a reset ep command. As
> long as the class driver doesn't submit a new URB to trigger a
> doorbell ring, the xhci driver can send a clear-halt after a reset ep
> command and no transfer will start.

Nope, for many years now, if not forever, xhci-hcd has been restarting
the endpoint after giving back the failed URB if its completion hasn't
unlinked all remaining URBs.

Changing this is one of the issues under discussion here. It would take
a few tweaks to the driver.

Per kerneldoc, you should unlink URBs before calling usb_clear_halt(),
and xHCI *requires* URBs to be unlinked in some situations, though you
wouldn't run into that if things worked the way you described.

It's another case when old USB2 spec arbitrarily dictates how software
should conduct its business and later xHCI assumes that we do. Annoying
as it is, it seems safer to follow the spec, particularly if URBs need
to be unlinked anyway to retry or replace the failed one.

Regards,
Michal