mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM <linux-pm@vger.kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	Maulik Shah <mkshah@codeaurora.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PM: runtime: Capture device status before disabling runtime PM
Date: Fri, 3 Dec 2021 13:26:55 -0500	[thread overview]
Message-ID: <Yaphb0hcqTQ3S78n@rowland.harvard.edu> (raw)
In-Reply-To: <4723000.31r3eYUQgx@kreacher>

On Fri, Dec 03, 2021 at 05:24:45PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> In some cases (for example, during system-wide suspend and resume of
> devices) it is useful to know whether or not runtime PM has ever been
> enabled for a given device and, if so, what the runtime PM status of
> it had been right before runtime PM was disabled for it last time.
> 
> For this reason, introduce a new struct dev_pm_info field called
> last_status that will be used for capturing the runtime PM status of
> the device when its power.disable_depth counter changes from 0 to 1.
> 
> The new field will be set to RPM_INVALID to start with and whenever
> power.disable_depth changes from 1 to 0, so it will be valid only
> when runtime PM of the device is currently disabled, but it has been
> enabled at least once.
> 
> Immediately use power.last_status in rpm_resume() to make it handle
> the case when PM runtime is disabled for the device, but its runtime
> PM status is RPM_ACTIVE more consistently.  Namely, make it return 1
> if power.last_status is also equal to RPM_ACTIVE in that case (the
> idea being that if the status was RPM_ACTIVE last time when
> power.disable_depth was changing from 0 to 1 and it is still
> RPM_ACTIVE, it can be assumed to reflect what happened to the device
> last time when it was using runtime PM) and -EACCES otherwise.
> 
> Update the documentation to provide a description of last_status and
> change the description of pm_runtime_resume() in it to reflect the
> new behavior of rpm_active().
> 
> While at it, rearrange the code in pm_runtime_enable() to be more
> straightforward and replace the WARN() macro in it with a pr_warn()
> invocation which is less disruptive.
> 
> Link: https://lore.kernel.org/linux-pm/20211026222626.39222-1-ulf.hansson@linaro.org/t/#u
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  Documentation/power/runtime_pm.rst |   14 +++++++++----
>  drivers/base/power/runtime.c       |   38 +++++++++++++++++++------------------
>  include/linux/pm.h                 |    2 +
>  3 files changed, 32 insertions(+), 22 deletions(-)
> 
> Index: linux-pm/drivers/base/power/runtime.c
> ===================================================================
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -744,11 +744,10 @@ static int rpm_resume(struct device *dev
>   repeat:
>  	if (dev->power.runtime_error)
>  		retval = -EINVAL;
> -	else if (dev->power.disable_depth == 1 && dev->power.is_suspended
> -	    && dev->power.runtime_status == RPM_ACTIVE)
> -		retval = 1;
>  	else if (dev->power.disable_depth > 0)
> -		retval = -EACCES;
> +		retval = dev->power.runtime_status == RPM_ACTIVE &&
> +			 dev->power.last_status == RPM_ACTIVE ? 1 : -EACCES;

Suggestion for a small improvement in readability: The way this 
statement is broken between two lines, it looks as if the ?: operator 
has higher precedence than the && operator, which is very confusing.  
Adding parentheses would help.  Even better would be to rewrite this as 
an "if" statement:

		if (dev->power.runtime_status == RPM_ACTIVE &&
		    dev->power.last_status == RPM_ACTIVE)
			retval = 1;
		else
			retval = -EACCES;

Alan Stern

  reply	other threads:[~2021-12-03 18:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 16:24 Rafael J. Wysocki
2021-12-03 18:26 ` Alan Stern [this message]
2021-12-03 19:40   ` Rafael J. Wysocki

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=Yaphb0hcqTQ3S78n@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=khilman@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mkshah@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=ulf.hansson@linaro.org \
    /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

all inboxes | Powered by JetHome®