On Thu, 5 Apr 2012, Chen Peter-B29397 wrote: > > > > - /* if !USB_SUSPEND, root hub timers won't get shut down ... */ > > > > - if (ehci->rh_state != EHCI_RH_RUNNING) > > > > - return 0; > > > > - > > > > /* init status to no-changes */ > > > > buf [0] = 0; > > > > ports = HCS_N_PORTS (ehci->hcs_params); > > > > @@ -572,6 +563,11 @@ ehci_hub_status_data (struct usb_hcd *hc > > > > retval++; > > > > } > > > > > > > > + /* Inform the core about resumes-in-progress by returning > > > > + * a non-zero value even if there are no status changes. > > > > + */ > > > > + status = ehci->resuming_ports; > > > > + > > > How about adding the code after spin_lock_irqsave (&ehci->lock, flags), > > it can increase > > > the coverage. > > > > The coverage doesn't matter. If a port starts resuming before this > > statement runs, it will be detected. If a port starts resuming > > after this statement then (since the root hub has already been > > suspended) the driver will call usb_hcd_resume_root_hub(), which will > > set the HCD_FLAG_WAKEUP_PENDING bit in hcd->flags, which will cause > > hcd-pci.c:suspend_common() to return -EBUSY. > > > 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. > Any suggestions if the wakeup occurs all USB stuffs system suspend routine have finished? Sorry, I don't understand this question. > 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
