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

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

On Fri, 30 Oct 2026 18:57:14 +0200, Mathias Nyman wrote:
> > 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

Fair enough.

> > 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.

The problem is: we need to detect those disconnections, and we rely
on aforementioned port state flags.

We only detect disconnection if an endpoint halts while the flag is
set. If the same endpoint halts a few ms later, and link is already
restored, the flag is cleared and we don't detect disconnection.
Many interrupt endpoints have long intervals and halt with a delay.

There is risk that the disconnection has caused permanent change in
HC state and some endpoints need those workarounds even if link is
restored, though the only documented case so far seems to be Henry
Tseng's Configure Endpoint bug.

> > 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.

If vdev reallocation implies that the slot is disablend and enabled
again, then any bad state goes away together with VDEV_PORT_ERROR.

If a slot survives a brief disconnect, I suppose we are hitting the
"resuscitation" case, so we should get a reset_device() call and
then clear VDEV_PORT_ERROR.

> > 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.
> [...]

Yes. But until 7.3, workarounds for disconnected devices were limited
to USB3 and nobody complained. The new Renesas disconnection bug seems
limited to USB3 devices too. So if this code continues to cause issues
with USB2 devices, restricting it to USB3 could be an option.

> > 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.

The point would be to buy time and see what's the bare minimum of
functional change to avoid bugs that are confirmed to exist.

But I start to see that if it turns out that all the functionality
implemented in 7.3 and the fixup patch is impossible to avoid, then
the code would end up similar in the end.

The biggest saving probably came from "cheating" and relying on
drivers unlinking their URBs in disconnect().

Regards,
Michal