[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Remy Bohmer]

Hi,

2010/8/31 Anatolij Gustschin <agust at denx.de>:
> Checking the status field of the qTD token in the current code
> do not take into acount cases where endpoint stall (halted) bit
> is set together with some other status bits. As a result clearing
> stall on an endpoint won't be done if other status bits were set.

Reading this description and this code:

>        /* special handling of STALL in DATA phase */
> -       if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
> +       if ((result < 0) &&
> +           (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
>                USB_STOR_PRINTF("DATA:stall\n");

Description and code do not seem to match. The old implementation
explicitly checked if the STALLED bit was set, and if so the endpoint
would be cleared. Now, it seems you are clearing the endpoint _also_
when the CRC_ERR bit is set.

There are a lot more reasons, at least on other host controllers that
set the status USB_ST_CRC_ERR, does this change not break the other
code? (A simple grep will show you the situations where it is
returned.)

> E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
> connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
> issue showed that while bulk IN transfers with length of 13 or
> 18 the status field of the qTD token sometimes indicates trans-
> action error (XactErr) and sometimes additionally endpoint halted
> state. In the latter case resetting the USB device in error
> recovery code fails as no clear stall request on the endpoint
> will be done.

OK

> However this fix is not enough to solve 'usb start' problem
> with hub/stick combination mentioned above. Running with lot of
> debug code in ehci_submit_async() I've never seen the problem
> with usb stick recognition. After removing this debug code the
> similar problem sometimes showed up again. Therefore the patch
> also adds delay in ehci_submit_async() for above-mentioned
> hub/stick combination. Even without this delay the fix is an

Why only for these USB sticks? Are these sticks special among the
thousands of different sticks out there?
Or could it be more reliable to always do this delay for all USB
sticks? Or even better, what are we missing here that the delay is
needed at all?

> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 37d056e..7463a75 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c

Is this problem only valid for the EHCI code? I can imagine that the
other host controllers (like UHCI and OHCI and so on) code suffer the
same problem and need similar fixes...
(At least I know that I have here a couple of USB sticks that show
similar problems with OHCI ;-) )

Kind regards,

Remy