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

[PATCH v2] 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. 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;
 	default:
 		/* do nothing */
 		break;

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

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

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

[Troy Mitchell]

[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Junzhong Pan]

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@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.
> 

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.

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