linux-kernel - Re: [PATCH v1 23/23] PM: runtime: Change pm_runtime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFrh0WHN0q2RU3POYLc7mkTdgg-8e8r7KVVmtd3MrUvWJg@mail.gmail.com>
Date: Sun, 28 Dec 2025 16:51:50 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Brian Norris <briannorris@...omium.org>
Subject: Re: [PATCH v1 23/23] PM: runtime: Change pm_runtime_put() return type
 to void

On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> The primary role of pm_runtime_put() is to decrement the runtime PM
> usage counter of the given device.  It always does that regardless of
> the value returned by it later.
>
> In addition, if the runtime PM usage counter after decrementation turns
> out to be zero, a work item is queued up to check whether or not the
> device can be suspended.  This is not guaranteed to succeed though and
> even if it is successful, the device may still not be suspended going
> forward.
>
> There are multiple valid reasons why pm_runtime_put() may not decide to
> queue up the work item mentioned above, including, but not limited to,
> the case when user space has written "on" to the device's runtime PM
> "control" file in sysfs.  In all of those cases, pm_runtime_put()
> returns a negative error code (even though the device's runtime PM
> usage counter has been successfully decremented by it) which is very
> confusing.  In fact, its return value should only be used for debug
> purposes and care should be taken when doing it even in that case.
>
> Accordingly, to avoid the confusion mentioned above, change the return
> type of pm_runtime_put() to void.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

Nice cleanup!

Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>

Kind regards
Uffe


> ---
>  include/linux/pm_runtime.h |   16 ++--------------
>  1 file changed, 2 insertions(+), 14 deletions(-)
>
> --- a/include/linux/pm_runtime.h
> +++ b/include/linux/pm_runtime.h
> @@ -545,22 +545,10 @@ static inline int pm_runtime_resume_and_
>   *
>   * Decrement the runtime PM usage counter of @dev and if it turns out to be
>   * equal to 0, queue up a work item for @dev like in pm_request_idle().
> - *
> - * Return:
> - * * 1: Success. Usage counter dropped to zero, but device was already suspended.
> - * * 0: Success.
> - * * -EINVAL: Runtime PM error.
> - * * -EACCES: Runtime PM disabled.
> - * * -EAGAIN: Runtime PM usage counter became non-zero or Runtime PM status
> - *            change ongoing.
> - * * -EBUSY: Runtime PM child_count non-zero.
> - * * -EPERM: Device PM QoS resume latency 0.
> - * * -EINPROGRESS: Suspend already in progress.
> - * * -ENOSYS: CONFIG_PM not enabled.
>   */
> -static inline int pm_runtime_put(struct device *dev)
> +static inline void pm_runtime_put(struct device *dev)
>  {
> -       return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_ASYNC);
> +       __pm_runtime_idle(dev, RPM_GET_PUT | RPM_ASYNC);
>  }
>
>  /**
>
>
>