On Sun, 24 Jan 2010, Rafael J. Wysocki wrote: > > There needs to be a public interface to this function available for > > drivers that have non-tree constraints. The arguments should be the > > device to wait for and the device doing the waiting (needed only to > > determine whether the caller is running synchronously or not). > > Something like the patch below? Yes, exactly. Thanks. > > This will be necessary for USB. In fact, your current code (with patch > > 7/8 applied) is subject to a race that will sometimes cause a > > non-high-speed USB device to fail to resume from hibernation. > > That's the kind of information I need at this point. What exactly should be > added to patch 7/8 to avoid this problem? I don't think there's anything you can do about it, really. It's an obscure USB issue: If an EHCI controller was reset or loses power during a system sleep (which always happens with hibernation and sometimes happens with suspend-to-RAM, depending on the chipset and firmware), then the EHCI controller must be resumed after all its sibling companion OHCI/UHCI controllers, and USB devices below the companion root hubs must be resumed after the EHCI root hub. With synchronous resume this happens automatically because the devices in question are always registered in the appropriate order. But the only way to meet these constraints with async resume is to add specific code to the USB core to enforce the non-tree orderings. I intend to write this code, but merging it will be a little tricky. You'll have to coordinate with Greg KH. If you have a non-high-speed USB device, you can test to see if this problem is not just a figment of my imagination. To violate the first constraint, add an ssleep(1) to the beginning of ohci_pci_resume() in drivers/usb/host/ohci-pci.c or to the beginning of uhci_pci_resume() in drivers/usb/host/uhci-hcd.c (depending on whether your companion controllers are OHCI or UHCI). To violate the second constraint, add an ssleep(1) to the beginning of ehci_bus_resume() in drivers/usb/host/ehci-hub.c. Either constraint violation should cause the device to be disconnected and then reconnected during an async resume from hibernation, as opposed to simply being reset. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
