[lkml]   [2011]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
On Sat, 15 Oct 2011, NeilBrown wrote:

> > One of the things Rafael didn't mention is that sometimes a kernel
> > driver needs to prevent the system from suspending. This happens when
> > recharging over a USB connection.
> >
> > There's no simple way for such a driver to communicate with a power
> > daemon. The driver has to use something like the wakeup mechanism --
> > but currently that mechanism is optional.
> >
> > Alan Stern
> Certainly I don't expect a kernel driver to communicate directly with a
> user-space daemon. It communicates indirectly through the wakeup_source
> mechanism.
> If user-space wants to block suspend, it talks to the suspend daemon (power
> manager) some how (dbus, lock files, sockets, signals, whatever).
> If the kernel wants to block suspend, it activates a wakeup_source (aka
> caffeine source) which the suspend daemon notices via /sys/power/wakeup_count.
> But you say this wakeup mechanism is optional .... I don't see that.
> It is implemented in drivers/base/power/wakeup.c which is included in the
> kernel if CONFIG_PM_SLEEP which is defined as
> config PM_SLEEP
> def_bool y
> which seems to mean "enable this unless we don't have suspend and we don't
> have hibernate".
> So it seems that the only time we don't have the wakeup mechanism, we also
> have no risk of ever going to sleep.
> What exactly where you saying was "optional"?? I don't understand.

It's optional in the sense that user programs can bypass it. They
aren't forced to read or write /sys/power/wakeup_countm, and if they
don't then the wakeup mechanism won't prevent the system from

Alan Stern

 \ /
  Last update: 2011-10-15 20:37    [W:0.088 / U:3.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site