[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 03 Mar 2016 12:24:23 -0800
From: Kevin Hilman <khilman@...libre.com>
To: Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] PM / Domains: Propagate start and restore errors during runtime resume
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com> writes:
> During runtime resume the return values of the start and restore steps
> are ignored. As a result drivers are not notified of runtime resume
> failures and can't propagate them up. Fix it by returning an error if
> either the start or restore step fails, and clean up properly in the
> error path.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
> ---
> drivers/base/power/domain.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> This fixes an issue I've noticed with my driver's .runtime_resume() handler
> returning an error that was never propagated out of pm_runtime_get_sync().
Acked-by: Kevin Hilman <khilman@...libre.com>
> A second issue then appeared. The device .runtime_error field is set to the
> error code returned by my .runtime_resume() handler, but it never reset. Any
> subsequent try to resume the device fails with -EINVAL. I'm not sure what the
> right way to solve that is, advices are welcome.
Probably setting it (back) to zero after each successful runtime_suspend
or runtime_resume is the right way. Rafael?
Kevin
Powered by blists - more mailing lists