Wakeup and S states
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?
Quoted 5 lines · Phillip Susi
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · Matthew Garrett
Quoted 5 lines · Phillip Susi
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?
Quoted 11 lines · Phillip Susi
Quoted 3 lines · Matthew Garrett
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?
Quoted 5 lines
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/wakeupclaims wakeup for the device is disabled. They should always agree shouldn't they?
They should - failure to do so seems like a bug.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 1 line · Matthew Garrett
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.
Quoted 10 lines · Phillip Susi
Quoted 1 line · Matthew Garrett
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 2 lines · Matthew Garrett
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.