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

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

[Junzhong Pan]

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.

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@linux.spacemit.com>
---
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.
+		 */
+		if (dwc->xhci)
+			pm_request_resume(&dwc->xhci->dev);
+		break;
 	default:
 		/* do nothing */
 		break;
--
2.25.1

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

[Greg Kroah-Hartman]

On Tue, Aug 11, 2026 at 05:08:17PM +0800, 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.
> 
> 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@linux.spacemit.com>
> ---
> base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
>  drivers/usb/dwc3/core.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

Did you get LLM help with creating this patch?

thanks,

greg k-h

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

[Junzhong Pan]

Hi Greg,

> Did you get LLM help with creating this patch?

YES and I missed the documentation [1] that work with LLM.
I'll add the tag in the next version.

Since this is an RFC patch, I would appreciate any comments
you may have on the approach of handling runtime resume for
ACPI dwc3 host.

[1] https://docs.kernel.org/process/coding-assistants.html

Thanks!

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

[Thinh Nguyen]

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@linux.spacemit.com>
> ---
> 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.

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

> +		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?

After the change:

Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>

Thanks,
Thinh

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@linux.spacemit.com>
>> ---
>> 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@synopsys.com>
> 
> Thanks,
> Thinh

Best regards.

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

[Thinh Nguyen]

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@linux.spacemit.com>
> >> ---
> >> 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?

BR,
Thinh