Skip to content
  • Rafael J. Wysocki's avatar
    PM: Make it possible to avoid races between wakeup and system sleep · c125e96f
    Rafael J. Wysocki authored
    
    
    One of the arguments during the suspend blockers discussion was that
    the mainline kernel didn't contain any mechanisms making it possible
    to avoid races between wakeup and system suspend.
    
    Generally, there are two problems in that area.  First, if a wakeup
    event occurs exactly when /sys/power/state is being written to, it
    may be delivered to user space right before the freezer kicks in, so
    the user space consumer of the event may not be able to process it
    before the system is suspended.  Second, if a wakeup event occurs
    after user space has been frozen, it is not generally guaranteed that
    the ongoing transition of the system into a sleep state will be
    aborted.
    
    To address these issues introduce a new global sysfs attribute,
    /sys/power/wakeup_count, associated with a running counter of wakeup
    events and three helper functions, pm_stay_awake(), pm_relax(), and
    pm_wakeup_event(), that may be used by kernel subsystems to control
    the behavior of this attribute and to request the PM core to abort
    system transitions into a sleep state already in progress.
    
    The /sys/power/wakeup_count file may be read from or written to by
    user space.  Reads will always succeed (unless interrupted by a
    signal) and return the current value of the wakeup events counter.
    Writes, however, will only succeed if the written number is equal to
    the current value of the wakeup events counter.  If a write is
    successful, it will cause the kernel to save the current value of the
    wakeup events counter and to abort the subsequent system transition
    into a sleep state if any wakeup events are reported after the write
    has returned.
    
    [The assumption is that before writing to /sys/power/state user space
    will first read from /sys/power/wakeup_count.  Next, user space
    consumers of wakeup events will have a chance to acknowledge or
    veto the upcoming system transition to a sleep state.  Finally, if
    the transition is allowed to proceed, /sys/power/wakeup_count will
    be written to and if that succeeds, /sys/power/state will be written
    to as well.  Still, if any wakeup events are reported to the PM core
    by kernel subsystems after that point, the transition will be
    aborted.]
    
    Additionally, put a wakeup events counter into struct dev_pm_info and
    make these per-device wakeup event counters available via sysfs,
    so that it's possible to check the activity of various wakeup event
    sources within the kernel.
    
    To illustrate how subsystems can use pm_wakeup_event(), make the
    low-level PCI runtime PM wakeup-handling code use it.
    
    Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
    Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    Acked-by: default avatarmarkgross <markgross@thegnar.org>
    Reviewed-by: default avatarAlan Stern <stern@rowland.harvard.edu>
    c125e96f