Re: [RFC PATCH] usb: dwc3: core: resume xHCI child on runtime resume in host mode

[Junzhong Pan]

On 8/27/2026 10:11 AM, Thinh Nguyen wrote:
> Hi,
> 
> On Tue, Aug 11, 2026, Junzhong Pan wrote:
>> USB controller runtime suspend halts the controller on disconnection.
>> It relies on platforms with custom connection notification to start
>> the controller again.
>>
>> The host branch of dwc3_runtime_resume() does nothing currently. There
>> are two paths that can trigger a runtime resume of the dwc3 core in
>> host mode:
>>
>> (a) Wake lands on the xHCI child (DT platforms, e.g. Qualcomm, i.MX8MP)
>>     A platform wakeup IRQ fires and the glue handler calls
>>     pm_runtime_resume(&xhci->dev). Runtime PM walks upward, resumes
>>     the dwc3 parent first, then resumes xHCI. Both wake correctly.
>>
>> (b) Wake lands on the dwc3 parent (ACPI platforms)
>>     When an ACPI Notify(ACPI_NOTIFY_DEVICE_WAKE) targets the dwc3
>>     parent device -- for example via a Generic Event Device on a
>>     hardware-reduced platform where dwc3 is enumerated as an ACPI
>>     device without a glue driver -- the ACPI core turns this into
>>     pm_request_resume(dwc3_dev). Runtime PM does not propagate resume
>>     downward, so the xHCI child stays suspended. Root hub polling is
>>     never re-armed, and a device plugged in while suspended is silently
>>     dropped.
> 
> Good catch.
> 
>>
>> This patch fills in the host branch to cover case (b) by requesting an
>> async resume of the xHCI child so xhci_resume() can restore the port
>> state machine and re-arm root hub polling. Async is required to avoid
>> deadlocking on the parent's own rpm_resume() re-entry.
>>
>> Signed-off-by: Junzhong Pan <panjunzhong@xxxxxxxxxxxxxxxxxx>
>> ---
>> base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
>>  drivers/usb/dwc3/core.c | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index ceb49f2f8004..bce56765ad90 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -2668,6 +2668,18 @@ int dwc3_runtime_resume(struct dwc3 *dwc)
>>  		}
>>  		break;
>>  	case DWC3_GCTL_PRTCAP_HOST:
>> +		/*
>> +		 * Only the xHCI child's resume re-arms root hub polling, which
>> +		 * is what rediscovers a device plugged in while suspended.
>> +		 * Runtime PM never resumes children on its own, so request it
>> +		 * here. This has to be asynchronous: resuming the child
>> +		 * synchronously would deadlock because rpm_resume() tries to
>> +		 * resume the parent before the child, and here the parent's
>> +		 * own callback has not returned yet.
>> +		 */
> 
> This note sounds as if this is needed to all cases, but you're only
> describing only case b) here. Can you also mention for case a) that
> there maybe an extra resume work call.

Will do.

> 
> Would be nice for it to be cleaner without the extra call, but I think
> it should be fine.

I guess we could do this: after this merged, we patch those platform
drivers(case a) to drop their existing workaround hack, dwc3 will
take over it's child xhci in this wakeup resume path, they just wake
dwc3. That makes things consistent. What do you think?

> 
>> +		if (dwc->xhci)
>> +			pm_request_resume(&dwc->xhci->dev);
>> +		break;
>>  	default:
>>  		/* do nothing */
>>  		break;
>> --
>> 2.25.1
>>
> 
> Thanks for the patch, can you resubmit with the proper assisted-by tag
> and remove the RFC?

Will do, thanks.

> 
> After the change:
> 
> Acked-by: Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx>
> 
> Thanks,
> Thinh

Best regards.