lkml.org 
[lkml]   [2014]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 2/3] PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
    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



    \
     
     \ /
      Last update: 2014-05-14 01:41    [W:2.935 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site