Re: [PATCH] usb: xhci: Add XHCI_TT_SOFT_RETRY quirk for transaction errors on TT devices

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

On Sat, 10 Oct 2026 11:25:18 +0800, Jie Deng wrote:
> Low-speed devices behind a high-speed hub on some xHCI controllers stop
> working after repeated lsusb -v: a transient USB transaction error on a
> bulk/interrupt endpoint is followed by a hard reset recovery where every
> command completes successfully (Reset EP with TSP=0 and Set TR Deq both
> return COMP_SUCCESS), but the first new split transaction issued after
> the restart fails again.  After two such cycles the hub reports a port
> connection change and the device drops off.

There are no bulk/interrupt endopints. Which one?
(I tried and lsusb -v does seem to trigger some interrupt transfers).

The patch seems LLM-generated.
Are you sure it's a HW problem and not an LLM problem?

> The affected silicon does not honor the xHCI spec (4.6.8) requirement
> that a Reset Endpoint command with TSP=0 "reset any USB2 split
> transaction state associated with the endpoint": the stale split state
> survives the reset, so the next split transaction carries the old
> transaction's identity and can never match the hub TT state, cleared
> or not.  The soft reset path (TSP=1), which per the spec maintains the
> split transaction state and retries the last transaction on the next
> doorbell, recovers these transient errors on the first retry.
> 
> Add a XHCI_TT_SOFT_RETRY quirk: when set, bulk/interrupt endpoints
> behind a TT hub may use the existing soft retry machinery to retry a
> USB Transaction Error (completion code 4) in place instead of going
> through the hard reset path.  Platforms without the quirk keep the
> exact previous behavior.  Isochronous and control endpoints never
> enter this function, and the existing MAX_SOFT_RETRY bound still falls
> back to the hard reset path for persistent errors.

Sounds like you may need Configure Endpoint recovery if you ever run
out of retries in any case other than disconnection.

> The quirk is meant to be set by platform code for controllers with
> this silicon bug; no in-tree platform code sets it yet.

Is support for this HW coming upstream anytime soon?
Not sure if we take fixes for out-of-tree issues.

> On the affected controller every error reports comp code 4 (USB
> Transaction Error), tt_info 0x301 and err_count 1, i.e. each in-place
> retry succeeds immediately and the fallback is never taken.
> 
> Signed-off-by: Jie Deng <dengjie03@kylinos.cn>

Suspecting missing Assisted-by.

Regards,
Michal