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). 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
