On Thu, Mar 3, 2016 at 9:32 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Thu, Mar 3, 2016 at 9:24 PM, Kevin Hilman <khil...@baylibre.com> wrote: >> Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.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+rene...@ideasonboard.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 <khil...@baylibre.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? > > That follows the assumption that runtime PM usually won't be reliable > after an error, so runtime_error has to be cleared explicitly via > pm_runtime_set_status().
Sorry, that won't work. Anyway, the idea is that the error has to be cleared manually after a failure.
