Hi Alan, I'm working on some patches to add USB 3.0 link power management to the USB core and xHCI. I think you already know that U1 and U2 are new link power states for USB 3.0 (although USB 2.1 has U1, sort of, with the L1 state). There are two ways to get into U1 or U2. The device can initiate the link state change, or the hub/roothub can initiate a link state change after an idle timeout. Either link partner can reject the request to go to a lower power state. A USB 3.0 modem might, for example, want to reject a request to go into U2 because it's in the middle of receiving a text message. For those classes of devices that can send data to the host through an interrupt endpoint, like modems or bluetooth, I think it makes sense to only allow device-initiated link state changes. The idea is the device knows when it needs to transmit data to the host, and it can quickly transition to a lower power link state after it's done sending data. If the host needs to send data through the device, the links will automatically get put into U0 by the hubs in the path to the device, and the hubs will force the links to stay in U0 until the packet is received. Then after the device gets the data, and transmits it through the radio, the device can quickly put the link back down into U2. If we have hub-initiated link state changes in this model, I think we will have a lot of churn for the device rejecting link power state transition requests, and I'm not sure if that will actually save power. I'm also concerned about "dumb" modems that always accept the link state change, and shutdown their radios, even though they are receiving data. The Intel Windows folks have come up with a list of device classes and what they think the device-initiated vs. hub-initiated link state policy should be. I'd like to duplicate that in Linux, so that we don't run into "broken" devices that work under the Windows policy but break under Linux. To that end, I'd like to add a new usb_device_driver field, disable_hub_initiated_lpm. If any interface driver for a device sets that flag, we won't set the U1/U2 link idle timeout values for its parent hub. We will allow the device to initiate a link state change, regardless of the flag state (later if we find truly broken devices, we might need a second flag). Does this policy sound reasonable? If so, I have a couple of questions about driver binding and disabling USB devices that are related. Sarah Sharp -- 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
