Re: [PATCH] drvier: usb: dwc3: Fix runtime PM trying to activate child device xxx.dwc3 but parent is not active

[Rafael J. Wysocki]

On Wed, Aug 27, 2025 at 4:52 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Ryan:
>
> You should present your questions to the maintainer of the kernel's
> Power Management subsystem, Rafael Wysocki (added to the To: list for
> this email).

Thanks Alan!


> On Wed, Aug 27, 2025 at 10:09:10PM +0800, ryan zhou wrote:
> > Hi Roy,
> > Thank you for reviewing my patch.
> > >
> > > Wouldn't the parent glue dev already resume before resuming the child dwc3?
> > >
> > No, in the following case, the parent device will not be reviewed
> > before resuming the child device.
> > Taking the 'imx8mp-dwc3' driver as an example.
> > Step 1.usb disconnect trigger: the child device dwc3 enter runtime
> > suspend state firstly, followed by
> > the parent device imx8mp-dwc3 enters runtime suspend
> > flow:dwc3_runtime_suspend->dwc3_imx8mp_runtime_suspend
> > Step2.system deep trigger:consistent with the runtime suspend flow,
> > child enters pm suspend and followed
> > by parent
> > flow: dwc3_pm_suspend->dwc3_imx8mp_pm_suspend
> > Step3: After dwc3_pm_suspend, and before dwc3_imx8mp_pm_suspend, a
> > task terminated the system suspend process
> > . The system will resume from the checkpoint, and resume devices in
> > the suspended state in the reverse
> > of pm suspend, but excluding the parent device imx8mp-dwc3 since it
> > did not execute the suspend process.
> >
> > >
> > >Why would 'runtime PM trying to activate child device xxx.dwc3 but parent is not active' happen in the first place?
> > >
> > Following the above analysis, dwc3_resume calls

I assume that dwc3_pm_resume() is meant here.

> > pm_runtime_set_active(dev), it checks the
> > parent.power->runtime_status is not RPM_ACTIVE and outputs the error log.

And it does so because enabling runtime PM for the child with
runtime_status == RPM_ACTIVE does not make sense when the parent has
runtime PM enabled and its status is not RPM_ACTIVE.

It looks like the runtime PM status of the parent is not as expected,
but quite frankly I don't quite follow the logic in dwc3_pm_resume().

Why does it disable runtime PM just for the duration of
dwc3_resume_common()?  If runtime PM is functional before the
pm_runtime_disable() call in dwc3_pm_resume(), the device may as well
be resumed by calling pm_runtime_resume() on it without disabling
runtime PM.  In turn, if runtime PM is not functional at that point,
it should not be enabled.