On Tue, 25 Sep 2012, Peter Chen wrote: > On Mon, Sep 24, 2012 at 12:23 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > It turns out that the USB-2 spec does not take into account the > > possibility of the race between a hub being suspended and one of its > > ports receiving a remote wakeup request from downstream. The > > flowcharts and discussions in Chapter 11 ignore the possibility > > completely. Depending on how closely a particular hub's implementation > > follows the treatment in the spec, if the two events happen at about > > the same time then it is possible for the hub to lose the wakeup > > request, and it is even possible for the hub to think the child device > > has been disconnected. I believe (though I'm not certain) that people > > have observed both these things happen during testing. > > > > The race _was_ recognized in one of the errata documents published > > after the USB-2.0 spec came out. The solution recommended in that > > document is exactly wrong! It says that all the enabled ports on a hub > > should be suspended before the hub is suspended -- this just makes the > > race more likely to occur. > > > > The only viable solution is to make sure that _none_ of a hub's ports > > are suspended when the hub is suspended. That way a downstream device > > will not be able to send a remote wakeup request until after the hub is > > fully suspended, so the race will never occur. > > > > (The situation for USB-3 hubs is somewhat different. Right now I'm > > only talking about USB-2 hubs, or the HS/FS/LS parts of USB-3 hubs.) > > > > For us to do this would be a little difficult. System suspend is easy > > enough to handle because we don't actually need to put any external > > ports into suspend; the entire bus will go into global suspend when the > > root hub is suspended. In fact, this is what we should be doing now > > (but we aren't). > > > Do you think is it OK to set ehci->no_selective_suspend = 1 for single > port controller? In general you should avoid setting that flag if possible. Setting it would prevent the attached device from being runtime suspended. But if that device is a hub, it wouldn't prevent the hub's children from being runtime suspended. The issue described in this email thread affects only external hubs, not root hubs. It's perfectly okay to suspend an EHCI root hub while the ports are suspended -- in fact, the EHCI spec requires this. > Currently, both ehci_hub_control and ehci_bus_suspend will go bus suspend > routine when CONFIG_USB_SUSPEND is defined, and I am not sure if > PSE and ASE is cleared before we let bus go to suspend (at ehci_hub_control). Where does ehci_hub_control put the bus into suspend? It suspends only individual ports, not the whole bus. If if there's only one port, suspending that port does not suspend the whole bus. The frame counter continues to update and the root hub will continue to respond to URBs. 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
