On Mon, Oct 01, 2012 at 03:53:03PM -0400, Alan Stern wrote: > On Mon, 1 Oct 2012, Sarah Sharp wrote: > > > > I don't remember the details. Doesn't usb_unlocked_disable_lpm() force > > > the device back into U0? You call that routine before suspending the > > > port. > > > > It sends the control transfer to bring the port from U1/U2 into U0 and > > disables any further device or hub initiated U1/U2 transitions. But it > > doesn't actually _wait_ for the port to enter U0. > > Would you have to poll for it in a loop? Actually, looking at the code, after we disable the parent U1/U2 timeouts, we send a control transfer to disable device-initiated U1/U2. The device must be in U0 to receive the control transfer, so the device is in U0 when usb_disable_lpm() returns. > > > But we don't when going into the FREEZE or PRETHAW stages of > > > hibernation -- all we do is call the bus_suspend routines for root > > > hubs. That may need to be changed for USB-3 buses. > > > > I think so. Where is the code that only calls bus_suspend? I'll take a > > stab at fixing it. > > generic.c:generic_suspend(). Note that nowadays, PM_EVENT_PRETHAW is > merely an alias for PM_EVENT_QUIESCE. 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. 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? 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
