> > 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. > > 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? > > Is it ok we stop system suspend at suspend_enter? > > If device_may_wakeup() is true for the controller then yes, it is okay > to stop system suspend. See the existing code in > hcd-pci.c:suspend_common() and hcd_pci_suspend(). In fact that code > checks twice, just before and just after suspending the controller. > Only the second check is needed for handling the race; the first check > is merely an optimization. > > 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 -- 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
