[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+zupgxMefawABGDkpRy9XmWJ5S50H1U9AF9V3UqX2b5G3pj-Q@mail.gmail.com>
Date: Fri, 13 Sep 2024 11:02:27 -0700
From: Roy Luo <royluo@...gle.com>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "badhri@...gle.com" <badhri@...gle.com>,
"frank.wang@...k-chips.com" <frank.wang@...k-chips.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v1] usb: dwc3: re-enable runtime PM after failed resume
On Fri, Sep 6, 2024 at 5:58 PM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
>
> On Fri, Sep 06, 2024, Roy Luo wrote:
> > When dwc3_resume_common() returns an error, runtime pm is left in
> > disabled state in dwc3_resume(). The next dwc3_suspend_common()
>
> What issue did you see when dwc3_suspend_common is not skipped?
Apologies for the delayed response.
To answer your question, if dwc3_suspend_common() isn't skipped, it
can lead to issues because dwc->dev is already in a suspended state.
This could mean its parent devices (like the power domain or glue
driver) are also suspended and may have released resources that dwc
requires.
Consequently, calling dwc3_suspend_common() in this situation could
result in attempts to access unclocked or unpowered registers.
Regards,
Roy Luo
Powered by blists - more mailing lists