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? > 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. > 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. > 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 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. Regards Oliver -- 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
