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

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Wed, Aug 27, 2025, Rafael J. Wysocki wrote:
> On Wed, Aug 27, 2025 at 4:52 PM Alan Stern <stern@rowland.harvard.edu> 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,

So is the scenario Ryan brought up unexpected? What are we missing here
and where should the fix be in?

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

Base on git-blame, I hope this will answer your question:

    68c26fe58182 ("usb: dwc3: set pm runtime active before resume common")

    For device mode, if PM runtime autosuspend feature enabled, the
    runtime power status of dwc3 may be suspended when run dwc3_resume(),
    and dwc3 gadget would not be configured in dwc3_gadget_run_stop().
    It would cause gadget connected failed if USB cable has been plugged
    before PM resume. So move forward pm_runtime_set_active() to fix it.


In certain platforms, they probably need the phy to be active to perform
dwc3_resume_common().

BR,
Thinh