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 Mon, 26 Oct 2026 14:56:49 -0400, Alan Stern wrote:
> You can read the login in hub.c:hub_port_connect_change().
> 
> Broadly speaking, if the port is enabled after a connect-change
> event, the core tries to resuscitate the child device (and checks
> whether the descriptors have changed).  Also, if the child device was
> suspended when the connect change occurred, the core will try to
> resuscitate it by treating the change as a wakeup event.

Thanks.

For USB2, this seems to happen if a reset was queued before a brief
disconnection and executed after it.

We believe the issues reported here happen when a device disappears,
usbhid sees -EPROTO and tries to reset it, then the device comes back.
But what happens to a device that reconnects during probe doesn't seem
to matter, as long as it ultimately gets probed (reasonably fast).

So I wonder how important is this feature and what motivated it? Are
there known use cases that depend on it? Like devices disappearing
mid-operation for a few ms which need to have their state preserved?
Should we worry about things breaking if xhci-hcd begins to act like
the device is gone: ESHUTDOWN completions, ENODEV on submit?

And if this happens to a hub, can we rely that its children will be
freed and reenumerated, or may they also get reused somehow? If they
can't, are they guaranteed to go away before the hub is reset?
(Because that would be convenient...)

Regards,
Michal