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

[Wolfgang Denk]

Dear Anatolij,

In message <AANLkTikbnmdtJNCjd-pjeHWsw+Ng8sTF1iZT1utG6JS8 at mail.gmail.com> Remy Bohmer wrote:
> 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 ;-) )


As far as I can tell you never replied to thesequestions, with the
result that this patch did not make it into mainline yet.

Could you please have a look?  Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.