linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	ryan zhou <ryanzhou54@gmail.com>, Roy Luo <royluo@google.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH] drvier: usb: dwc3: Fix runtime PM trying to activate child device xxx.dwc3 but parent is not active
Date: Wed, 3 Sep 2025 17:54:12 -0400	[thread overview]
Message-ID: <59951c2d-60e8-47a8-a43c-00b92e095043@rowland.harvard.edu> (raw)
In-Reply-To: <CAJZ5v0h=i9XF_SQMOhz3P+4SAH3Qy-r1oUiiw7Bp=PcRnJjVbQ@mail.gmail.com>

On Wed, Sep 03, 2025 at 09:30:47PM +0200, Rafael J. Wysocki wrote:
> I personally think that it would be reasonable to simply preserve
> device states in error paths unless they have been changed already
> before the error (or suspend abort due to a wakeup signal).

The problem is complicated by the interaction between runtime-PM states 
and system-sleep states.  In the case, we've been considering, B changes 
from runtime-suspended to runtime-suspended + system-suspended.  
Therefore the error path is allowed to modify B's state.

> By this rule, B would be left in runtime suspend if it were still in
> runtime suspend when the error (or suspend abort in general) occurred
> and then it doesn't matter what happens to A.

More fully, B would be changed from runtime-suspended + system-suspended 
back to simply runtime-suspended.  Unfortunately, none of the PM 
callbacks in the kernel are defined to make this change -- at least, not 
without some cooperation from the driver.

> The PM core can do something like that for the drivers opting in for
> runtime PM integration assistance, so to speak.  That is, drivers that
> point their ->suspend() and ->resume() callbacks to
> pm_runtime_force_suspend() and pm_runtime_force_resume(),
> respectively, or set DPM_FLAG_SMART_SUSPEND (or both at the same time
> which is now feasible).  Otherwise, it is hard to say what the
> expectations of the driver are and some code between the driver and
> the PM core may be involved (say, the PCI bus type).

Setting DPM_FLAG_SMART_SUSPEND really does sound like the best answer.

But there still should be some way the PM core can make resumes easier 
for drivers that don't set the flag.  Something like: If the device is 
in runtime suspend with SMART_SUSPEND clear, perform a runtime resume on 
the device's parent (and anything else the device depends on) before 
invoking ->resume.

Alan Stern

      reply	other threads:[~2025-09-03 21:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26 15:08 [PATCH] drvier: usb: dwc3: Fix runtime PM trying to activate child device xxx.dwc3 but parent is not active Ryan Zhou
2025-08-26 18:38 ` Roy Luo
2025-08-27 14:09   ` ryan zhou
2025-08-27 14:52     ` Alan Stern
2025-08-27 18:56       ` Rafael J. Wysocki
2025-08-29  0:43         ` Thinh Nguyen
2025-08-29  1:25           ` Alan Stern
2025-08-29 19:07             ` Thinh Nguyen
2025-08-29 19:26               ` Rafael J. Wysocki
2025-08-29 20:13                 ` Thinh Nguyen
2025-08-30  0:46                   ` Alan Stern
2025-08-30  1:14                     ` Thinh Nguyen
2025-08-29 19:23             ` Rafael J. Wysocki
2025-08-29 19:58               ` Alan Stern
2025-09-01 19:41                 ` Rafael J. Wysocki
2025-09-01 20:40                   ` Rafael J. Wysocki
2025-09-02  2:41                     ` Alan Stern
2025-09-03 11:51                       ` ryan zhou
2025-09-03 19:30                       ` Rafael J. Wysocki
2025-09-03 21:54                         ` Alan Stern [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59951c2d-60e8-47a8-a43c-00b92e095043@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=royluo@google.com \
    --cc=ryanzhou54@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).