Wakeup and S states

Wakeup and S states

[Phillip Susi]

It looks like the PM core has an all or nothing concept of whether a 
device can and should wake the system, but in ACPI, the answer to these 
depends on what S state you are talking about.  If you look at 
/proc/acpi/wakeup, it lists the lowest S state each device is capable of 
waking the system in, but device_can_wakeup() appears to just check an 
all or nothing flag, rather than consider what S state we may be 
transitioning to.  If a device is capable of wakeup from S3, but we are 
going to S4, then won't device_can_wakeup() return true, and thus, the 
driver will mistakenly try to enable wakeup when hibernating?

Conversely, if an ethernet controller is capable of waking up the system 
from S5, that does not mean we want it left powered on and capable of 
doing so when we shut the machine off, but had WOL enabled.  Is there no 
way to enable wakeup only from S3, even though the device is capable of 
lower levels?

Re: Wakeup and S states

[Matthew Garrett]

On Wed, Jun 15, 2011 at 11:12:03AM -0400, Phillip Susi wrote:

> Conversely, if an ethernet controller is capable of waking up the
> system from S5, that does not mean we want it left powered on and
> capable of doing so when we shut the machine off, but had WOL
> enabled.  Is there no way to enable wakeup only from S3, even though
> the device is capable of lower levels?

Well, that's the usual use-case for WoL. If you don't want a device to 
wake up from a specific sleep state, disable that device before entering 
that sleep state.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Wakeup and S states

[Phillip Susi]

On 06/15/2011 11:44 AM, Matthew Garrett wrote:
> On Wed, Jun 15, 2011 at 11:12:03AM -0400, Phillip Susi wrote:
>
>> Conversely, if an ethernet controller is capable of waking up the
>> system from S5, that does not mean we want it left powered on and
>> capable of doing so when we shut the machine off, but had WOL
>> enabled.  Is there no way to enable wakeup only from S3, even though
>> the device is capable of lower levels?
>
> Well, that's the usual use-case for WoL. If you don't want a device to
> wake up from a specific sleep state, disable that device before entering
> that sleep state.

I am reading reports from some users that their laptop keeps the
ethernet interface powered on and runs down the battery after shutting
down.  It seems they are capable of waking the system from S5.  It 
appears that if the interface is not ethdown'ed in /etc/init.d/halt, 
then it remains on.  Are you saying that it is up to userspace to 
disable WOL and down the interface before shutting down?

Also strangely, ethtool reports that WOL is enabled for magic packet ( 
which I guess comes from the bios default, I checked my desktop and it 
also appears to default to wol: g, but can only wakeup from s4 ), but 
/proc/acpi/wakeup claims wakeup for the device is disabled.  They should 
always agree shouldn't they?

Re: Wakeup and S states

[Matthew Garrett]

On Thu, Jun 16, 2011 at 09:48:59AM -0400, Phillip Susi wrote:
> On 06/15/2011 11:44 AM, Matthew Garrett wrote:
> >Well, that's the usual use-case for WoL. If you don't want a device to
> >wake up from a specific sleep state, disable that device before entering
> >that sleep state.
> 
> I am reading reports from some users that their laptop keeps the
> ethernet interface powered on and runs down the battery after shutting
> down.  It seems they are capable of waking the system from S5.  It
> appears that if the interface is not ethdown'ed in /etc/init.d/halt,
> then it remains on.  Are you saying that it is up to userspace to
> disable WOL and down the interface before shutting down?

Yes. How would the kernel know that you don't want WoL in that case?

> Also strangely, ethtool reports that WOL is enabled for magic packet
> ( which I guess comes from the bios default, I checked my desktop
> and it also appears to default to wol: g, but can only wakeup from
> s4 ), but /proc/acpi/wakeup claims wakeup for the device is
> disabled.  They should always agree shouldn't they?

They should - failure to do so seems like a bug.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Wakeup and S states

[Phillip Susi]

On 6/16/2011 10:15 AM, Matthew Garrett wrote:
> Yes. How would the kernel know that you don't want WoL in that case?

That was my original point; the kernel architecture seems lacking since 
it does not consider what S state you are talking about wrt wakeup 
capability and policy.  I can see the argument that policy should be 
dynamically changed in user space, but it seems that the kernel really 
needs to track the capability as it relates to S state so you don't try 
to enable wakeup in states where it is not possible.

Re: Wakeup and S states

[Matthew Garrett]

On Thu, Jun 16, 2011 at 10:32:29AM -0400, Phillip Susi wrote:
> On 6/16/2011 10:15 AM, Matthew Garrett wrote:
> >Yes. How would the kernel know that you don't want WoL in that case?
> 
> That was my original point; the kernel architecture seems lacking
> since it does not consider what S state you are talking about wrt
> wakeup capability and policy.  I can see the argument that policy
> should be dynamically changed in user space, but it seems that the
> kernel really needs to track the capability as it relates to S state
> so you don't try to enable wakeup in states where it is not
> possible.

But you're complaining about the case where wakeup is enabled in a case 
where it *is* possible. Userspace needs to take care of that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Wakeup and S states

[Phillip Susi]

On 6/16/2011 10:37 AM, Matthew Garrett wrote:
> But you're complaining about the case where wakeup is enabled in a case
> where it *is* possible. Userspace needs to take care of that.

I am concerned about both cases.  It would /like/ to be able to set the 
policy to wakeup only on state X and lower, and it seems like this would 
be better done in the kernel than user space, but it seems a kernel bug 
to enable wakeup in states that are higher than where it is supported.