From: Steve Glendinning <hidden> Date: 2012-11-28 08:34:59
Hi Alan,
quoted
udev->do_remote_wakeup is set in choose_wakeup() in
drivers/usb/core/driver.c. AFAICS it is always set as long as
device_may_wakeup(&udev->dev) is true.
That's right. But is device_may_wakeup(&udev->dev) true?
By default it wouldn't be. The normal way to set it is for the user or
a program to do:
echo enabled >/sys/bus/usb/devices/.../power/wakeup
Of course, a driver could disregard the user's choice and set the flag
by itself.
If I set that from userspace the system is able to resume, but I can't
work out how to successfully set this from the driver. I believe the
driver should be overriding this as if the user has asked for the
device to wake on lan they're expecting this to resume the system.
I've tried placing various combinations of device_set_wakeup_capable
and device_set_wakeup_enable in different places (bind, suspend), but
it still doesn't allow the device to resume from suspend. How should
I do this?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
udev->do_remote_wakeup is set in choose_wakeup() in
drivers/usb/core/driver.c. AFAICS it is always set as long as
device_may_wakeup(&udev->dev) is true.
That's right. But is device_may_wakeup(&udev->dev) true?
By default it wouldn't be. The normal way to set it is for the user or
a program to do:
echo enabled >/sys/bus/usb/devices/.../power/wakeup
Of course, a driver could disregard the user's choice and set the flag
by itself.
If I set that from userspace the system is able to resume, but I can't
work out how to successfully set this from the driver. I believe the
driver should be overriding this as if the user has asked for the
device to wake on lan they're expecting this to resume the system.
I've tried placing various combinations of device_set_wakeup_capable
and device_set_wakeup_enable in different places (bind, suspend), but
it still doesn't allow the device to resume from suspend. How should
I do this?
I may be completely wrong here, but this is how I believe it is supposed
to work... The device can be suspended for two possible reasons:
1) system suspend. If the user want the device to wake the system, then
(s)he will do
echo enabled >/sys/bus/usb/devices/.../power/wakeup
If this isn't set, then there is no reason for the driver to request
remote wakeup while the system is suspended.
2) autosuspend. Any interface driver needing remote wakeup will set
intf->needs_remote_wakeup, which makes autosuspend_check() set
udev->do_remote_wakeup
If all my guesses and assumptions are right, then you want to set
intf->needs_remote_wakeup unconditionally. This will make the USB core
enable remote wakeup on autosuspend.
Remote wakeup will not be enabled on system suspend unless the user (or
a userspace program on the users behalf) has requested it.
Bjørn
From: Steve Glendinning <hidden> Date: 2012-11-28 10:16:28
Hi Bjorn,
On 28 November 2012 09:31, Bjørn Mork [off-list ref] wrote:
Remote wakeup will not be enabled on system suspend unless the user (or
a userspace program on the users behalf) has requested it.
If a user types "ethtool -s eth2 wol p" they *are* explicitly
requesting the ethernet device to bring the system out of suspend, so
I think the ethernet driver should set the feature automatically.
from drivers/base/power/wakeup.c:
* By default, most devices should leave wakeup disabled. The exceptions are
* devices that everyone expects to be wakeup sources: keyboards, power buttons,
* possibly network interfaces, etc.
Steve
Hi Bjorn,
On 28 November 2012 09:31, Bjørn Mork [off-list ref] wrote:
quoted
Remote wakeup will not be enabled on system suspend unless the user (or
a userspace program on the users behalf) has requested it.
If a user types "ethtool -s eth2 wol p" they *are* explicitly
requesting the ethernet device to bring the system out of suspend, so
I think the ethernet driver should set the feature automatically.
from drivers/base/power/wakeup.c:
* By default, most devices should leave wakeup disabled. The exceptions are
* devices that everyone expects to be wakeup sources: keyboards, power buttons,
* possibly network interfaces, etc.
Right. That seems logical. But the ethtool setting should still
probably be reflected in the device attributes so that the user can see
them there?
Just doing a simple test of what other ethernet drivers does, I tried
this on the e1000e adapter in my laptop. Initially:
nemi:/tmp# grep . /sys/bus/pci/devices/0000:00:19.0/power/*
/sys/bus/pci/devices/0000:00:19.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:19.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:19.0/power/control:auto
/sys/bus/pci/devices/0000:00:19.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:19.0/power/runtime_active_time:266378772
/sys/bus/pci/devices/0000:00:19.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:19.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:19.0/power/runtime_suspended_time:568333816
/sys/bus/pci/devices/0000:00:19.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup:disabled
nemi:/tmp# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Enabling WOL:
nemi:/tmp# ethtool -s eth0 wol p
nemi:/tmp# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: pumbg
Wake-on: p
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
nemi:/tmp# grep . /sys/bus/pci/devices/0000:00:19.0/power/*
/sys/bus/pci/devices/0000:00:19.0/power/async:enabled
grep: /sys/bus/pci/devices/0000:00:19.0/power/autosuspend_delay_ms: Input/output error
/sys/bus/pci/devices/0000:00:19.0/power/control:auto
/sys/bus/pci/devices/0000:00:19.0/power/runtime_active_kids:0
/sys/bus/pci/devices/0000:00:19.0/power/runtime_active_time:266414488
/sys/bus/pci/devices/0000:00:19.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/0000:00:19.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:19.0/power/runtime_suspended_time:568333816
/sys/bus/pci/devices/0000:00:19.0/power/runtime_usage:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup:enabled
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_abort_count:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_active:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_active_count:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_count:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_expire_count:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_last_time_ms:834745779
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_max_time_ms:0
/sys/bus/pci/devices/0000:00:19.0/power/wakeup_total_time_ms:0
So this driver does set wakeup:enabled, and if this had been a USB
device then the USB core would have set the Remote Wakeup feature on
suspend without the driver having to do anything special in its
driver->suspend function.
Looking at the different ethernet drivers, the normal way do do this
seems to be something like this in their .set_wol implementation:
device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
where "adapter" is a netdev_priv private struct, "pdev" is a pci device
and "wol" is an u32. I don't see any problem doing the same for USB
network devices implementing ethtool "set_wol".
Note that according to Documentation/power/devices.txt:
"Device drivers, however, are not supposed to call device_set_wakeup_enable()
directly in any case."
which I guess really means that wakeup:enabled is supposed to be user
controlled and not driver controlled. I assume the ethtool userspace
interface make the above void, as drivers implementing the ethtool
interface will have to call device_set_wakeup_enable() to syncronize
ethtool and sysfs settings.
Does this make sense?
Bjørn