[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPwe5RNddK2=bvrd6h_xyxH+SDDx7kx2tyDKRhyuDGvHYewGvg@mail.gmail.com>
Date: Thu, 11 Sep 2025 21:40:48 +0800
From: ryan zhou <ryanzhou54@...il.com>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "rafael@...nel.org" <rafael@...nel.org>,
"royluo@...gle.com" <royluo@...gle.com>
Subject: Re: [PATCH v2] drvier: usb: dwc3: Fix runtime PM trying to activate
child device xxx.dwc3 but parent is not active
Thinh Nguyen <Thinh.Nguyen@...opsys.com> 于2025年9月11日周四 09:32写道:
>
> On Wed, Sep 10, 2025, Ryan Zhou wrote:
> > Issue description:During the wake-up sequence, if the system invokes
> > dwc3->resume and detects that the parent device of dwc3 is in a
> > runtime suspend state, the system will generate an error: runtime PM
> > trying to activate child device xxx.dwc3 but parent is not active.
> >
> > Solution:At the dwc3->resume entry point, if the dwc3 controller
> > is detected in a suspended state, the function shall return
> > immediately without executing any further operations.
> >
> > Signed-off-by: Ryan Zhou <ryanzhou54@...il.com>
> > ---
> > drivers/usb/dwc3/core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > index 370fc524a468..06a6f8a67129 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -2687,6 +2687,9 @@ int dwc3_pm_resume(struct dwc3 *dwc)
> > struct device *dev = dwc->dev;
> > int ret = 0;
> >
> > + if (pm_runtime_suspended(dev))
> > + return ret;
> > +
>
> Is this a documented behavior where the device should remain runtime
> suspend on system resume? I feel that that this should be configurable
> by the user or defined the PM core. I don't think we should change
> default behavior here just to workaround the issue that we're facing.
No documentation was found, but modifying the runtime suspend state
after wakeup from sleep seems unnecessary if the device was already
in runtime suspend before sleep.
> What if the user wants to keep the old behavior and resume up the device
> on system resume?
For USB devices, RPM resume should be initiated by plug/unplug events,
not PM resume when the device is physically disconnected.
Thanks,
Ryan
Powered by blists - more mailing lists