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

Junzhong Pan panjunzhong at linux.spacemit.com
Tue Sep 8 07:01:20 PDT 2026


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 at synopsys.com>
Assisted-by: Opencode:claude-opus-5
Signed-off-by: Junzhong Pan <panjunzhong at 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;
 	default:
 		/* do nothing */
 		break;

---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260908-resume-xhci-0fa34ff9b332

Best regards,
-- 
Junzhong Pan <panjunzhong at linux.spacemit.com>




More information about the linux-riscv mailing list