On Mon, Jun 09, 2025 at 03:20:47PM +0300, Mathias Nyman wrote:
USB3 devices connected behind several external suspended hubs may not be detected when plugged in due to aggressive hub runtime pm suspend.
The hub driver immediately runtime-suspends hubs if there are no active children or port activity.
There is a delay between the wake signal causing hub resume, and driver visible port activity on the hub downstream facing ports. Most of the LFPS handshake, resume signaling and link training done on the downstream ports is not visible to the hub driver until completed, when device then will appear fully enabled and running on the port.
This delay between wake signal and detectable port change is even more significant with chained suspended hubs where the wake signal will propagate upstream first. Suspended hubs will only start resuming downstream ports after upstream facing port resumes.
The hub driver may resume a USB3 hub, read status of all ports, not yet see any activity, and runtime suspend back the hub before any port activity is visible.
This exact case was seen when conncting USB3 devices to a suspended Thunderbolt dock.
USB3 specification defines a 100ms tU3WakeupRetryDelay, indicating USB3 devices expect to be resumed within 100ms after signaling wake. if not then device will resend the wake signal.
Give the USB3 hubs twice this time (200ms) to detect any port changes after resume, before allowing hub to runtime suspend again.
Cc: stable@vger.kernel.org Fixes: 596d789a211d ("USB: set hub's default autosuspend delay as 0") Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com
Acked-by: Alan Stern stern@rowland.harvard.edu