diff options
author | Sarah Sharp <sarah.a.sharp@linux.intel.com> | 2012-01-06 15:48:30 -0800 |
---|---|---|
committer | Sarah Sharp <sarah.a.sharp@linux.intel.com> | 2012-02-14 12:12:23 -0800 |
commit | 3b9b6acd4798aafe9b9f64ccb7e8eb76f27f904a (patch) | |
tree | eed2db913bdb2c1cd465a857b6175e9e3c4cbf55 /drivers/usb/core | |
parent | 623bef9e03a60adc623b09673297ca7a1cdfb367 (diff) | |
download | op-kernel-dev-3b9b6acd4798aafe9b9f64ccb7e8eb76f27f904a.zip op-kernel-dev-3b9b6acd4798aafe9b9f64ccb7e8eb76f27f904a.tar.gz |
USB: Suspend functions before putting dev into U3.
The USB 3.0 bus specification introduces a new type of power management
called function suspend. The idea is to be able to suspend different
functions (i.e. a scanner or an SD card reader on a USB printer)
independently. A device can be in U0, but have one or more functions
suspended. Thus, signaling a function resume with the standard device
remote wake signaling was not possible.
Instead, a device will (without prompt from the host) send a "device
notification" for the function remote wake. A new Set Feature Function
Remote Wake was developed to turn remote wake up on and off for each
function.
USB 3.0 devices can still go into device suspend (U3), and signal a
remote wakeup to bring the link back into U1. However, they now use the
function remote wake device notification to allow the host to know which
function woke the device from U3.
The spec is a bit ambiguous about whether a function is allowed to
signal a remote wakeup if the function has been enabled for remote
wakeup, but not placed in function suspend before the device is placed
into U3.
Section 9.2.5.1 says "Suspending a device with more than one function
effectively suspends all the functions within the device." I interpret
that to mean that putting a device in U3 suspends all functions, and
thus if the host has previously enabled remote wake for those functions,
it should be able to signal a remote wake up on port status changes.
However, hub vendors may have a different interpretation, and it can't
hurt to put the function into suspend before putting the device into U3.
I cannot get an answer out of the USB 3.0 spec architects about this
ambiguity, so I'm erring on the safe side and always suspending the
first function before placing the device in U3. Note, this code should
be fixed if we ever find any USB 3.0 devices that have more than one
function.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Diffstat (limited to 'drivers/usb/core')
-rw-r--r-- | drivers/usb/core/hub.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 50411cd..70622d6 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2437,7 +2437,8 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE, USB_INTRF_FUNC_SUSPEND, - USB_INTRF_FUNC_SUSPEND_RW, + USB_INTRF_FUNC_SUSPEND_RW | + USB_INTRF_FUNC_SUSPEND_LP, NULL, 0, USB_CTRL_SET_TIMEOUT); } |