Re: Re [patch 2/3] fastboot: turn the USB hostcontroller initcallsinto async initcalls

From: Simon Arlott
Date: Sat Jul 19 2008 - 11:32:36 EST

On 19/07/08 16:25, Alan Stern wrote:
On 18 July, 2008, Arjan van de Ven wrote:

From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Subject: [PATCH] fastboot: turn the USB hostcontroller initcalls into async initcalls

the USB host controller init calls take a long time, mostly due to a
"minimally 100 msec" delay *per port* during initialization.
These are prime candidates for going in parallel to everything else.

The USB device ordering is not affected by this due to the
serialized-within-eachother property of async initcalls.

Is there some reason this patch wasn't posted to the linux-usb mailing
list as well as to LKML?

Where is this "minimally 100 msec" per-port delay you refer to? Offhand I can't recall any such delays in the init routines.


/* USB 2.0 spec, / fig 7-29:
* Between connect detection and reset signaling there must be a delay
* of 100ms at least for debounce and power-settling. The corresponding
* timer shall restart whenever the downstream port detects a disconnect.
* Apparently there are some bluetooth and irda-dongles and a number of
* low-speed devices for which this debounce period may last over a second.
* Not covered by the spec - but easy to deal with.
* This implementation uses a 1500ms total debounce timeout; if the
* connection isn't stable by then it returns -ETIMEDOUT. It checks
* every 25ms for transient disconnects. When the port status has been
* unchanged for 100ms it returns the port status.

Could it do that for all ports on the hub in parallel instead?

Simon Arlott
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at