On Mon, Mar 07, 2011 at 11:11:52AM -0500, Alan Stern wrote: > The hcd->state variable is a disaster. It's not clearly owned by > either usbcore or the host controller drivers, and they both change it > from time to time, potentially stepping on each other's toes. It's > not protected by any locks. And there's no mechanism to prevent it > from going through an invalid transition. > > This patch (as1451) takes a first step toward fixing these problems. > As it turns out, usbcore uses hcd->state for essentially only two > things: checking whether the controller's root hub is running and > checking whether the controller has died. Therefore the patch adds > two new atomic bitflags to the hcd structure, to store these pieces of > information. The new flags are used only by usbcore, and a private > spinlock prevents invalid combinations (a dead controller's root hub > cannot be running). > > The patch does not change the places where usbcore sets hcd->state, > since HCDs may depend on them. Furthermore, there is one place in > usb_hcd_irq() where usbcore still must use hcd->state: An HCD's > interrupt handler can implicitly indicate that the controller died by > setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a > big improvement over the current code. > > The patch makes one other change. The hcd_bus_suspend() and > hcd_bus_resume() routines now check first whether the host controller > has died; if it has then they return immediately without calling the > HCD's bus_suspend or bus_resume methods. > > This fixes the major problem reported in Bugzilla #29902: The system > fails to suspend after a host controller dies during system resume. > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Tested-by: Alex Terekhov <a.terekhov@xxxxxxxxx> > CC: <stable@xxxxxxxxxx> So this should go to the .37 and .38 tree when it hits Linus's tree (I'm guessing it's too late for .38-final right now), do you think it's worth backporting this to .32 as well? thanks, greg k-h -- 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
