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

[Thinh Nguyen]

On Sat, Aug 29, 2026, Junzhong Pan wrote:
> 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.

Thanks for the info. Please mention this in the commit message so we can
reference the real platform/user should we need to review this in the
future.

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

That's great! Those patches can be submitted after this one is merged.
We can gather more feedback from other users on those platforms.

BR,
Thinh