Re: [PATCH v2] usb: hub: fix detection of high tier USB3 devices behind suspended hubs

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

On 24.6.2025 2.32, Alan Stern wrote:
> On Mon, Jun 23, 2025 at 10:31:17PM +0200, Konrad Dybcio wrote:
>> On 6/11/25 1:24 PM, 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: 2839f5bcfcfc ("USB: Turn on auto-suspend for USB 3.0 hubs.")
>>> Acked-by: Alan Stern <stern@rowland.harvard.edu>
>>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>>> ---
>> Hi, this patch seems to cause the following splat on QC
>> SC8280XP CRD board when resuming the system:
>>
>> [root@sc8280xp-crd ~]# ./suspend_test.sh
>> [   37.887029] PM: suspend entry (s2idle)
>> [   37.903850] Filesystems sync: 0.012 seconds
>> [   37.915071] Freezing user space processes
>> [   37.920925] Freezing user space processes completed (elapsed 0.001 seconds)
> I don't know what could be causing this problem.
> 
> However, Mathias, I did notice a minor error in the patch when I read it
> again.  It's in the new part of hub_activate() which does this:
> 
> +		queue_delayed_work(system_power_efficient_wq, &hub->init_work,
> +				   msecs_to_jiffies(USB_SS_PORT_U0_WAKE_TIME));
> +		usb_autopm_get_interface_no_resume(
> +			to_usb_interface(hub->intfdev));
> 
> Once queue_delayed_work() has been called, it's possible that the work
> routine will run before the usb_autopm_get_interface_no_resume() call
> gets executed.  These two calls should be made in the opposite order.

Thanks, I'll fix that

-Mathias