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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
