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. A TI TUSB8040 USB 3.0 hub evaluation board I have was not actually signaling a remote wakeup when a new device was plugged in while the hub was suspended. Putting the function into suspend (not just enabling function wake) before putting the device in U3 made the hub start signaling remote wakeups. 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 can't tell what other vendor's interpretations of the spec are, since the other prototype I have repeatedly disconnects when I enable selective suspend. I would be happy to drop this patch if TI says I just need a firmware update for my board. It probably hasn't been updated since October 2010? Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> Cc: Dwight Schauer <dschauer@xxxxxx> Cc: Kevin Main <kmain@xxxxxx> --- 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 3cbba4f..39f3e4c 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2397,7 +2397,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); } -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
