On Tue, 14 Aug 2012, Rafael J. Wysocki wrote:
>
> The power.deferred_resume can only be set if the runtime PM status
> of device is RPM_SUSPENDING and it should be cleared after its
> status has been changed, regardless of whether or not the runtime
> suspend has been successful. However, it only is cleared on suspend
> failure, while it may remain set after successful suspend and is
> happily leaked to rpm_resume() executed in that case.
>
> That shouldn't happen, so if power.deferred_resume is set in
> rpm_suspend() after the status has been changed to RPM_SUSPENDED,
> clear it before calling rpm_resume(). Then, it doesn't need to be
> cleared before changing the status to RPM_SUSPENDING any more,
> because it's always cleared after the status has been changed to
> either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).
>
> Signed-off-by: Rafael J. Wysocki <r...@sisk.pl>
> ---
> drivers/base/power/runtime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux/drivers/base/power/runtime.c
> ===================================================================
> --- linux.orig/drivers/base/power/runtime.c
> +++ linux/drivers/base/power/runtime.c
> @@ -388,7 +388,6 @@ static int rpm_suspend(struct device *de
> goto repeat;
> }
>
> - dev->power.deferred_resume = false;
> if (dev->power.no_callbacks)
> goto no_callback; /* Assume success. */
>
> @@ -440,6 +439,7 @@ static int rpm_suspend(struct device *de
> wake_up_all(&dev->power.wait_queue);
>
> if (dev->power.deferred_resume) {
> + dev->power.deferred_resume = false;
> rpm_resume(dev, 0);
> retval = -EAGAIN;
> goto out;
Basically this comes down to a matter of taste. I tend to use a "lazy"
approach, not initializing values until they need to contain a proper
value (and not worrying if they contain garbage or wrong values at
times when they won't be used).
But of course, this is fine too. With this change, you can also
simplify one of the tests in rpm_check_suspend_allowed().
Acked-by: Alan Stern <st...@rowland.harvard.edu>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
