Re: [RFC][PATCH 2/3] PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily

[Alan Stern]

On Tue, 13 May 2014, Rafael J. Wysocki wrote:

> > A wakeup request from the hardware could cause a runtime resume to 
> > occur at this time.  The barrier wouldn't prevent that.
> > 
> > It's unlikely, I agree, but not impossible.
> 
> Yeah, I didn't think about that.

Come to think of it, if the hardware sends a wakeup request then it
must have been enabled for remote wakeup.  And if the hardware settings
are appropriate for system suspend then it must be enabled for system
wakeup.  Consequently a wakeup from the hardware ought to abort the
system suspend in any case.  So maybe we don't care about this 
scenario.

On the other hand, there may be other mechanisms that could cause a 
runtime resume at this inconvenient time.  A timer routine, for 
instance.

> But that also can occur in __device_suspend(), after we've checked the flag
> and decided not to invoke the ->suspend() callback, right?  So moving the
> check in there doesn't help much I'd say.  It closes the race window, but
> that's it.
> 
> That means that the whole approach based on ->prepare() is problematic
> unless we somehow mix it with disabling runtime PM.

Maybe the call to __pm_runtime_disable() should be moved from
__device_suspend_late() to __device_suspend(), after the callback has
been invoked (or skipped, as the case may be).  Then after runtime PM
has been disabled, you can check the device's status has changed and go
back to invoke the callback if necessary.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/