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

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

[Junzhong Pan]

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

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.

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

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@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://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20260811090817.109350-1-panjunzhong@linux.spacemit.com/__;!!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