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

[Jie Deng]

Hi Michal,
Thanks for the review.

在 2026/10/10 13:52, Michal Pecio 写道:
> 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).
It is an interrupt IN endpoint. The affected device is a low-speed
HID mouse behind a high-speed hub (slot 2, ep 2, interrupt IN,
MPS 8). You are right that bulk is not possible at low speed. The
commit message is wrong on this point.
> The patch seems LLM-generated.
> Are you sure it's a HW problem and not an LLM problem?
I used an LLM to help draft the commit message, and the wording
shows. The hardware problem is real. The controller is an SoC
integrated xHCI in a Phytium FT-D3000M. Repeater: run `lsusb -v` on
the low-speed mouse approximately <N> times. The mouse disconnects
within <N> rounds.
Raw dmesg from one run (xhci dynamic debug enabled):
    Transfer error for slot 2 ep 2 on endpoint
    Set TR Deq Ptr cmd, new deq ptr = 0x..., new cycle = 0
    Giveback URB ..., len = 0, expected = 5, status = -71
    Successful Set TR Deq Ptr cmd, deq = @0x...
    Transfer error for slot 2 ep 2 on endpoint
    Successful Set TR Deq Ptr cmd, deq = @0x... (+0x10)
    usb 9-1.3: USB disconnect, device number 8
Every error reports comp code 4, tt_info 0x301, err_count 1.
The dequeue pointer advances exactly one TRB (16 bytes) per cycle,
consistent with a single split-transaction retry that fails and is
re-issued with stale state.
> > 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.
Agreed. The current fallback after MAX_SOFT_RETRY is still the hard
reset path (break -> finish_td -> EP_HARD_RESET), which on this
controller does not clear the split-transaction state. I will
investigate whether Configure Endpoint can serve as the recovery
path for persistent errors and test it on the hardware.
> Is support for this HW coming upstream anytime soon?
> Not sure if we take fixes for out-of-tree issues.
The FT-D3000M platform code is not currently on an upstream track.
Whether it will be submitted later is undetermined.