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

[Junzhong Pan]

Hi Thinh,

On 8/28/2026 7:42 AM, Thinh Nguyen wrote:
> On Thu, Aug 27, 2026, Junzhong Pan wrote:
>>
>> 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?
>>
> 
> That would need to be validated on a case-by-case basis. Also, regarding
> testing, I assume this change has been tested on real hardware. If so,
> which platform(s) were tested?

Yes, I have tested on SpacemiT K3 Pico‑ITX , ACPI boot with a GED
Device to Nofity dwc3 node（HID 808622B7）of wakeup, and also DT boot
cases.

As for the DT boot(using modified dwc3-generic-plat driver), I verified
the extra call is handled well by pm framework checking RPM_ACTIVE. I
will mention this on next send.

I have also tested the extra call removed case by using a similar code
of qcom/imx8mp, but just replace the xhci->dev with dwc->dev, it works
find. But if need to send those patches, testing for regression helps
are still needed from who have these two platforms available I think?

> 
> BR,
> Thinh

Best regards.