On Fri, 6 Apr 2012, Chen Peter-B29397 wrote: > > > > So, for non-pci usb controller, like many embedded SoCs, we need to > > check > > > HCD_FLAG_WAKEUP_PENDING at controller's suspend or USB phy's suspend to > > avoid this race. > > > > That's right. Just as there is a race at the root hub level between > > suspending and receiving a wakeup request, a similar race exists at the > > controller level. The only way to handle it is to check, _after_ the > > controller has been suspended, whether the root hub has made a wakeup > > request. > > > After the controller has been suspended, how do we know root hub has made > a wakeup request, there is no usb code running after host controller has > been suspended. If the root hub made a wakeup request before the controller was suspended then HCD_FLAG_WAKEUP_PENDING will be set. If the root hub makes a wakeup request after the controller is suspended then the controller will turn on its own wakeup request. With PCI it is the PME# signal; on an SoC this could be a GPIO or IRQ line. If this happens while the system is still awake then the platform code is responsible for receiving the request and aborting the system suspend. And if this happens after the system is asleep then the PME# or GPIO or IRQ signal should wake up the system. > > > Any suggestions if the wakeup occurs all USB stuffs system suspend > > routine have finished? > > > > Sorry, I don't understand this question. > > > It is the same question like above, maybe for x86, it PCI bus has already been suspended, > there is a remote wakeup occurs, which place is better to avoid system enters > suspend? suspend_enter at kernel/power/suspend.c? Assuming the system hasn't already entered suspend, the right way to avoid it is to call pm_wakeup_event(). (See the kerneldoc in drivers/base/power/wakeup.c.) That's what the PCI subsystem does when running under ACPI: drivers/pci/pci-acpi.c:pci_acpi_wake_dev() calls pci_wakeup_event(), which is an inline for pm_wakeup_event(). 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
