> > > > > > - /* 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. Any suggestions if the wakeup occurs all USB stuffs system suspend routine have finished? Is it ok we stop system suspend at suspend_enter? > 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
