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? 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). > Runtime suspend is harder to handle. The hub_suspend() routine would > have to make the suspend feature is turned off for all the ports > attached to devices that are enabled for remote wakeup before allowing > the hub to suspend. The hub_resume() routine would either have to > re-enable the suspend feature for those ports or else cause all the > wakeup-enabled children to be resumed when the hub is. No matter how > we handle it, the result will be pretty inefficient. > > I don't know what we should do. Suggestions, anybody? > > 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 -- 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
