On Mon, 16 Jul 2012, Ming Lei wrote: > On Wed, Jul 11, 2012 at 11:23 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > This patch (as1589) resolves some unlikely races involving system > > shutdown or controller death in ehci-hcd: > > > > Shutdown races with both root-hub resume and controller > > resume. > > > > Controller death races with root-hub suspend. > > > > A new bitflag is added to indicate that the controller has been shut > > down (whether for system shutdown or because it died). Tests are > > added in the suspend and resume pathways to avoid reactivating the > > controller after any sort of shutdown. > > --- usb-3.4.orig/drivers/usb/host/ehci-hub.c > > +++ usb-3.4/drivers/usb/host/ehci-hub.c > > @@ -221,6 +221,8 @@ static int ehci_bus_suspend (struct usb_ > > ehci_quiesce(ehci); > > > > spin_lock_irq (&ehci->lock); > > + if (ehci->rh_state < EHCI_RH_RUNNING) > > + goto done; > > > > /* Once the controller is stopped, port resumes that are already > > * in progress won't complete. Hence if remote wakeup is enabled > > @@ -306,6 +308,10 @@ static int ehci_bus_suspend (struct usb_ > > ehci_halt (ehci); > > > > spin_lock_irq(&ehci->lock); > > + if (ehci->enabled_hrtimer_events & BIT(EHCI_HRTIMER_POLL_DEAD)) > > + ehci_handle_controller_death(ehci); > > I am wondering that why the above two lines are added, since ehci_halt has been > completed, and the hrtimer will be canceled soon. If the controller has died then we want the ehci_handle_controller_death callback to run, because it does several important things (set the rh_state to EHCI_RH_HALTED, clear the configured_flag, and so on). As you point out, the hrtimer will be cancelled soon, which means we can't depend on the timer to run the callback. 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
