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@synopsys.com>
> Assisted-by: Opencode:claude-opus-5
> Signed-off-by: Junzhong Pan <panjunzhong@linux.spacemit.com>
> ---
> Changes since RFC:
> - add Assisted-By tag and collect tag
> - refine the commit message and comments as suggested
>
> Link to RFC: https://lore.kernel.org/linux-usb/20260811090817.109350-1-panjunzhong@linux.spacemit.com/
> ---
>  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.

Would both devices return to autosuspend after the read and still
detect a subsequent plug-in? This would help cover the non-wakeup
case.
>  	default:
>  		/* do nothing */
>  		break;
>
> ---
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> change-id: 20260908-resume-xhci-0fa34ff9b332
>
> Best regards,


-- 
Troy Mitchell