On Thu, Apr 26, 2012 at 02:28:59PM -0400, Alan Stern wrote:
> This patch (as1549) fixes a rare problem affecting at least one OHCI
> controller: The controller requires a delay of at least 1 microsecond
> following a reset, even though it says that it is ready immediately.
>
> The fix is to do the delay first, before checking whether the reset is
> complete in the retry loop.
>
> Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> Reported-by: Calin Demian <c.demian20@xxxxxxxxx>
> CC: <stable@xxxxxxxxxxxxxxx>
>
> ---
>
> drivers/usb/host/pci-quirks.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: usb-3.4/drivers/usb/host/pci-quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/usb/host/pci-quirks.c
> +++ usb-3.4/drivers/usb/host/pci-quirks.c
> @@ -520,9 +520,10 @@ static void __devinit quirk_usb_handoff_
>
> /* reset requires max 10 us delay */
> for (cnt = 30; cnt > 0; --cnt) { /* ... allow extra time */
> + /* Some controllers enable HCR too soon, so always delay some */
> + udelay(1);
So we just slowed down the init sequence here by 1us for all systems due
to one specific broken machine?
When we have systems that are working really hard to tweak out the
fastest boot speed possible, is this really advisable?
How about a hardware-specific quirk here for such broken hardware
instead?
thanks,
greg k-h
--
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
