Re: [REGRESSION] usbhid -110 timeouts and reset loop for Keychron M5 (3434:d068) at boot since v7.3

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

On Sat, 31 Oct 2026 12:32:38 -0400, Alan Stern wrote:
> The USB-Persist stuff in the hub driver was originally motivated by the 
> desire to recover from disconnections during system suspend.  For 
> example, disconnections caused by host controllers that don't provide 
> Vbus power while they are suspended, or users unplugging a device while 
> the system is suspended and then plugging it back in before the system 
> resumes.  A more detailed description, somewhat out of date by now, is 
> given in the changelog for 8808f00c7adf ("USB: try to salvage lost power 
> sessions").
> 
> Yes, this feature is very important.  Mostly it was meant for USB 
> mass-storage devices going away and then reappearing following a system 
> resume.  Before the USB-Persist facility was added, if the device held a 
> mounted filesystem the result would _not_ be what users desired, to put 
> it mildly.  The ability to handle transient disconnections was just an 
> unintended side benefit, although there did seem to be some real cases 
> where it helped -- USB mice or something like that.
> 
> To the device and driver, what happens looks like a reset, or rather, a 
> reset-resume because the former configuration and altsettings are 
> restored.  Naturally any ongoing operations would be expected to be cut 
> short, but while the device is suspended this isn't an issue.
> 
> It seems that you're concerned about two slightly different types of 
> thing.  In one, the disconnection happens while the device is suspended 
> and it is discovered when we want to resume the device.  Presumably 
> that's not a problem for you (?), because in this case we really do go 
> through the whole reset-resume procedure.

Suspend and USB-Persist is a thing to keep in mind to avoid breaking,
but intended behavior change is only to drivers with URBs pending or
submitted on a disconnected device. We would like to reject such URBs
on devices behind disconnected root hub ports.

Maybe I will just say what I'm looking for to avoid XY problems: we
need a "barrier" which separates URBs (and ideally state changes like
deconfiguration) related to the pre-disconnection state from those
related to the post-reconnection state, when a udev is "rescued" and
the HCD must accept URBs to it again.

A suspended device has no URBs, so the barrier only needs to be one-
sided. I guess root hub port reset or hcd->driver->reset_device() on
the device or any of its upstream hubs is good enough

(Current logic in 7.3 watches for individual reset_device() calls
or RH port reconnection; the latter is clearly less than ideal for
USB3, and Sashiko thinks there are other issues.)

> When a hub is reset, the logic for what happens to its children is a 
> little tricky to follow. I think that each port with a connected
> child ends up being handled by hub_port_connect_change(), which
> treats it as a new connection _unless_ the child was suspended
> beforehand, in which case we follow the reset-resume path. So yes,
> it is possible for the child will be reused in this way.

Hmm, what about hub_pre_reset()? It seems to usb_disconnect() all
children when it runs. I would expect even a suspended child to be
permanently forgotten before the hub is reset.

Unless the hub itself was suspended and gets reset-resumed instead,
I suppose. But then everything is quiescent so no problem.

If core can promise that children are suspended or already deleted
when a hub gets reset, we could use hub reset as one barrier for the
hub and all children, without tracking this per-device.

I implemented this barrier logic and it seems to work as expected,
and ftrace shows that hub_pre_reset() runs and drops children. But
it works != it always works != it will stay working...

> But even when the children aren't reused, unless their 
> udev->persist_enabled flag is clear, they don't go away until well
> after the hub has been reset.  The reason is that the hub driver has
> to look at each one, after the hub is running again, and evaluate
> whether the connection can be recovered.  Maybe this can be improved.

That sounds like suspend and reset-resume of the hub. Considering
hub_pre_reset(), it hopefully doesn't happen on awake hubs.

> The case you mentioned, about a reset being queued but not occurring 
> until after a transient disconnection, is a little different from the 
> other cases.  The core basically ignores disconnections while a reset
> is in progress (in USB-2, the electrical signalling used during a
> reset actually makes it impossible for the upstream port to tell
> whether the device remains connected or not). Disconnections before
> a reset starts end up getting handled much the same way; the most
> that happens is that the connect-change status is cleared and the
> reset is retried.
>
> This was all implemented before USB-3 appeared.  If we were to do it 
> again now, we might do it differently.

Thanks, good to know. It is maybe not a big deal to maintain this
"resuscitation" of awake devices. It seems similar to recovery from
USB3 SS.Inactive state - logical link error without disconnection,
software may try to Warm Reset the device. (I don't have any repro
and don't know if it's handled here).

Regards,
Michal