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

[Thinh Nguyen]

On Fri, Sep 18, 2026, Junzhong Pan wrote:
> On 9/9/2026 8:28 PM, Junzhong Pan wrote:
> > On 9/8/2026 10:16 PM, Troy Mitchell wrote:
> >> On Tue Sep 8, 2026 at 10:01 PM +08, 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. Glue drivers in case (a)
> >>> resume xHCI directly, an extra call introduced by this change, but
> >>> runtime PM can serialize those requests and skip device already active,
> >>> so the extra resume call is safe. Those calls can be replaced with
> >>> resume calls to dwc3 device later.
> >>>
> >>> Tested on SpacemiT K3 Pico-ITX, covering both wakeup paths: an ACPI
> >>> boot with a GED device notifying the dwc3 node (HID 808622B7), and a
> >>> DT boot with a modified dwc3-generic-plat driver exposing a wakeup IRQ
> >>> similar to dwc3-qcom.c and dwc3-imx8mp.c. This is not validation on
> >>> actual Qualcomm or i.MX8MP hardware, changing those drivers would still
> >>> need platform-specific testing.
> >>>
> >>> Acked-by: Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx>
> >>> Assisted-by: Opencode:claude-opus-5
> >>> Signed-off-by: Junzhong Pan <panjunzhong@xxxxxxxxxxxxxxxxxx>
> >>> ---
> >>> Changes since RFC:
> >>> - add Assisted-By tag and collect tag
> >>> - refine the commit message and comments as suggested
> >>>
> >>> Link to RFC: https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20260811090817.109350-1-panjunzhong@xxxxxxxxxxxxxxxxxx/__;!!A4F2R9G_pg!fG8BhOaAiW3KsJBgmdcmOIKvYAFkNqYGGmoZn0ktdqp55U4q4kO1wKNFeAJ7YaGKoEWpwzyZAWYtypcFTR6doz7Ny1H6LQS2$ 
> >>> ---
> >>>  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 fd5c2cd36c59..76883dc6184c 100644
> >>> --- a/drivers/usb/dwc3/core.c
> >>> +++ b/drivers/usb/dwc3/core.c
> >>> @@ -2739,6 +2739,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 doesn't resume children, so request it here.
> >>> +		 * Keep it asynchronous to avoid waiting for the parent's resume
> >>> +		 * callback to finish from inside it. Glue drivers may also
> >>> +		 * resume xHCI directly, but runtime PM will serialize those
> >>> +		 * requests and skips an already-active device.
> >>> +		 */
> >>> +		if (dwc->xhci)
> >>> +			pm_request_resume(&dwc->xhci->dev);
> >>> +		break;
> >> Could we also check a parent-only resume with no USB wake event? For
> >> example, reading the DWC3 debugfs lsp_dump file calls
> >> pm_runtime_resume_and_get(dwc->dev). With both devices suspended, this
> >> change would wake xHCI too.
> >>
> > 
> > Thanks for pointing out, I did missed those paths before, I will do some
> > investigation and testing on the two non-wakeup path:debugfs attr access
> > and the dwc3_set_mode() path then report back.
> > 
> 
> I looked into this on real hardware. There are two paths where the
> resume is unnecessary:
> 
> (1) debugfs read: it briefly resumes xhci, then both devices go back
> to autosuspend. Harmless, though unnecessary.
> 
> (2) __dwc3_set_mode() while suspended in host mode: when a DRD
> controller is suspended in host mode and user or a role-switch consumer
> calls set_mode(), dwc3 is resumed first and the xhci removal follows.
> But pm_request_resume() only queues work, and the unregister path
> calls cancel_work_sync() before freeing the device, so the request
> is either cancelled or completes beforehand. In my testing, the PM
> core simply bails out with -EINVAL on pm_request_resume(&dwc->xhci->dev),
> and the removal completes fine.
> 
> I think yes there will be more extra calls here but they don't break
> things, I didn't reproduce any failure. It seems difficult to get rid
> of them since there are no good conditions to judge.
> 
> If we want to avoid these more extras, maybe those platform who need
> this feature can just let glue driver (dwc3-generic-plat.c or another)
> handle the ACPI probe and the wakeup (like qcom/imx8mp) together for
> the case(a) platform mentioned before instead of reusing the current
> 8080:22B7 ACPI probe path in dwc3/core.c .
> 
> Thinh, do you have any thought on that?  I'm fine with either approach.
> 

Troy brought up a good point. It may be "harmless" in the sense that it
doesn't prevent the device from functioning, but it unnecessarily
resumes xhci for other dwc3 runtime resume paths. We shouldn't apply
this generically to all platforms.

Please drop my Acked-by for now until we find a better solution.

I think handling the wakeup through a glue driver like qcom as you
suggested may be a better approach.

Thanks,
Thinh