Re: [PATCH v2] xhci: give back TDs and clean up ep0 after disconnect

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 10/30/26 14:05, Michal Pecio wrote:
> On Fri, 30 Oct 2026 13:05:16 +0200, Mathias Nyman wrote:
>>> And sashiko seems to object to it, is that response correct?
>>>    
>>
>> It does find one potential case where this patch does not fix the
>> enumeration of devices that disconnect during reset.
> 
> Honestly, is this 7.3 code being fixed here reliable at all?
> 
> As Sashiko points out (and I did before), we are 100% at the mercy of
> hardware and USB core with those "connected" and "link error" flags.
> Sashiko thinks that we may fail to clear these flags in some cases.
> Is it guaranteed that we can't clear them prematurely at other times?

'connected' and 'link error' flags can't be cleared prematurely, they
can be cleared late in case xHC doesn't generate port change events
for port changes. (change bits uncleared, hub driver is polling)

Sashiko reports the exact same issue in your 4/4 patch.

We can fix that, ask Dennis Wissel and Yiyu Zhou nicely if they still
can run one more test round. Maybe even make sashiko happy.


> 
> If USB3 link comes back after core has cleared all status change bits
> (brief disconnection), we will get another Port Status Change Event,
> observe the port in "Connected/U0" state and reset these flags.

This is what we want.
These flags are tracking root port states, not trying to track usb device
states

> 
> Is it guaranteed that core won't clear change bits until it finishes
> disconnection of affected devices so that all URBs are unlinked and
> we can no longer run into those HW bugs anymore?

No, and that is not the goal.
We are trying to avoid excessive endpoint state mangling after devices
are disconnected. We avoided too much in 7.3 when we left ep0 in a bad
state, assuming it will be dropped and freed after a disconnect.

> 
> If this fails to work, it's another regression vs 7.2 and prior. The
> old VDEV_PORT_ERROR flag used to stick for device lifetime. And it
> could have been extended to all disconnected devices, not just the
> one directly attached to the root port, to fix disconnection of whole
> trees with hubs while avoiding the above race condition.

moving the flags to all child vdev devices won't help, you
have all the same issues, plus the fact that vdevs are sometines
reallocated mid enumeration, and sometimes will stick even if device
briefly disconnects mid enumeration, just like ep0.

> 
> The reported USB2 regressions would have also been avoided, because
> old code only applied to USB3 ports and there is no actual need to
> generalize it to USB2 at this time. The bug still affected USB3, but
> it seems nobody uses USB3 devices that trigger it.

It's more about the hosts than the devices.

It appears some xHC hosts stop reporting endpoint states and changes
correctly some time after roothub connection is gone.

I recall some xHC had to disable soft retry because it almost immediately
went to some internal sleep state after last usb device was disconnected.

xhci driver first tried to soft-reset endpoint a few times, then hard-reset,
set-TR deq, restart ring, then hub driver noticed disconnect, cancelled URBs
which lead to trying to stopping the endpoint again.

At this point xHC no longer responded to stop endpoint command,
so xhci driver assumed host was broken.

once a new device was connected to host it immediately 'woke up'
and processed all endpoint related commands correctly.

> 
> I suppose I could fix the Renesas disconnection issue which the 7.3
> rework tried to address with an alternative patch smaller than this
> fixup, provided that the whole series is reverted. The preexisting
> USB3 bug would remain unsolved for now, however.

Doesn't make sense to start from scratch because of this sashiko report.
You'll just run into a new set of issues and regressions.

Thanks
Mathias