On Sun, 23 Sep 2012, Oliver Neukum wrote: > On Sunday 23 September 2012 12:23:40 Alan Stern wrote: > > It turns out that the USB-2 spec does not take into account the > > The race _was_ recognized in one of the errata documents published > > after the USB-2.0 spec came out. The solution recommended in that > > link?
This is in the May 28, 2002 errata document (2002_05_28_errata.pdf), which is part of the USB-2.0 ZIP file currently available at http://www.usb.org/developers/docs/usb_20_071012.zip. The particular text is on p.3: "Chapter 10: Add host software requirement to suspend downstream ports before suspending a hub:". > > 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. > > Only if remote wakeup is enabled. If remote wakeup is not enabled then there is no race in the first place, so it certainly will never occur. If you mean that it's okay to leave ports suspended if the devices attached to the ports aren't enabled for remote wakeup, then yes, I agree. > > 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 guess the worst case of waking up all but one is unavoidable > as a worst case. Do you mean that we will have N-1 unnecessary wakeups if N children are enabled for remote wakeup? It's actually worse than that -- the reason for resuming the hub may be something other than a wakeup request. In that case we would have N unnecessary wakeups. In the end it would probably be simpler to re-enable the suspend feature on those ports. > > I don't know what we should do. Suggestions, anybody? > > Merge the power transitions as much as possible if remote wakeup > is requested. That would mean > > a) divorce logically suspending a device and suspending the port I'm not sure we should do this. When the device is logically suspended, the driver cancels all the outstanding URBs and relies on the remote wakeup mechanism for notifications of important events. If the device isn't physically suspended then it can't send wakeup requests. > b) if the last port is "logically" to be suspended within a certain period > (eg. again the autosuspend delay) of a device defer the physical suspend of > other devices > c) if all devices are logically suspended suspend the uppermost possible > parent > physically and logically immediately > > That is the best I can come up with. The alternative seems to be ignoring the whole issue and hope that it goes away in time. I doubt this will work out well; there are people who require reliable wakeup handling. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
