[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7rPOt0x5hWncjhr@black.fi.intel.com>
Date: Sun, 23 Feb 2025 09:33:14 +0200
From: Raag Jadav <raag.jadav@...el.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Alan Stern <stern@...land.harvard.edu>,
Ulf Hansson <ulf.hansson@...aro.org>,
Oliver Neukum <oneukum@...e.com>,
Ajay Agarwal <ajayagarwal@...gle.com>,
Brian Norris <briannorris@...gle.com>
Subject: Re: [PATCH v1] PM: runtime: Unify error handling during suspend and
resume
On Thu, Feb 20, 2025 at 09:18:23PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> There is a confusing difference in error handling between rpm_suspend()
> and rpm_resume() related to the special way in which the -EAGAIN and
> -EBUSY error values are treated by the former. Also, converting
> -EACCES coming from the callback to an I/O error, which it quite likely
> is not, may confuse runtime PM users a bit.
>
> To address the above, modify rpm_callback() to convert -EACCES coming
> from the driver to -EAGAIN and to set power.runtime_error only if the
> return value is not -EAGAIN or -EBUSY.
>
> This will cause the error handling in rpm_resume() and rpm_suspend() to
> work consistently, so drop the no longer needed -EAGAIN or -EBUSY
> special case from the latter and make it retry autosuspend if
> power.runtime_error is unset.
>
> Link: https://lore.kernel.org/linux-pm/20220620144231.GA23345@axis.com/
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
> drivers/base/power/runtime.c | 34 ++++++++++++++++++----------------
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -448,8 +448,13 @@
> retval = __rpm_callback(cb, dev);
> }
>
> - dev->power.runtime_error = retval;
> - return retval != -EACCES ? retval : -EIO;
> + if (retval == -EACCES)
> + retval = -EAGAIN;
While this is one way to address the problem, are we opening the door
to changing error codes when convenient? This might lead to different
kind of confusion from user standpoint.
Raag
Powered by blists - more mailing lists