On Thu, 11 Oct 2012, Sarah Sharp wrote: > Thinking about this further, USB 2.1 devices need to be brought out of > their low power link state (L1) before they are suspended. Some xHCI > host controllers have hardware-driven USB 2.1 LPM, so the device could > have been put in L1 before hibernation. Therefore we need to suspend > USB 2.1 and USB 3.0 devices before we hibernate. I need to go through the LPM document more carefully before I can answer fully. However, what about disabling LPM instead of going all the way into suspend? For USB 2.1 devices at least? > Should we suspend all USB 2.0 devices, or should we only suspend devices > with bcdUSB 2.1 and higher? If we only suspend the USB 2.1 devices, > will that work if there is a USB 2.1 hub with USB 2.0 children? Here's more or less what I'd like to do (I don't know which parts will work with USB-3 hubs and devices, though): In generic_suspend, skip calling usb_port_suspend for FREEZE and PRETHAW events (just as we do now). In usb_port_suspend, set the wakeup feature as we do now. But if the event is for a system sleep, don't set the port-suspend feature but do disable LPM. In hub_suspend, if the event is a runtime suspend, clear the port-suspend feature for any children that have wakeup enabled. Keep track of which ports they were on for later use. In hub_resume, if the event is a runtime resume, queue a runtime-resume request for the devices attached to those ports. Also, prevent the hub from going back into runtime suspend until all those resumes have completed. Partly this is to optimize system suspend, and partly it is to work around the child-wakeup-request vs. port-suspend race. At this time I'm not sure if it will interact correctly with USB >=2.1 LPM. Alan Stern -- 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
