[U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Wolfgang Denk
wd at denx.de
Tue Nov 2 20:53:00 CET 2010
Dear Remy,
In message <AANLkTimtZosBtOBM_oG304GbRCpcm1WJEt0xqo+mgN9D at mail.gmail.com> you wrote:
>
> I have no idea what has been done, and has not been done. I have not
> been debugging this issue. I have no idea if a USB protocol analyser
> has shown something weird or something we could work on.
Sorry - we don;t have a USB protocol analyzer that does high-speed.
So our debugging is mostly limited to what we can see in the
controller, and in the software levels above it.
> But anyway: You admit that the problem is not understood, so would the
> delay fix the problem, or just make it less obvious?
You know that I cannot really answer this question. Without exact
understanding what is going on it is just a pretty much dirty work
around. It helps in this specific test case, but we have zero
knowledge if it helps in opther cases, and what these cases may be.
The "interesting" part of these tests was that the problem really
sticks to one specific combination of hub and storage device.
> If we would allow such workarounds to U-boot we would end up with
> endless lists of device-ids that are excluded in some situation all
> over the place.
> The code would just become fluttered with all kinds of exceptions to
> mask problems not being understood and not being debugged properly.
Agreed.
> And in this case: How big is the chance that any other user will have
> exact the same hardware combination and run into this problem? I guess
> that would be close to zero... My guts tells me that the chance that
> other combinations require the same 'fix' is bigger...
I am positive sure that other uses with this hardware combination
_will_ run into the same problem. This fix was developed for a
customer who needed it pretty much urgently because he was using this
combo in numbers where he preferred paying for the fix over throwing
away the sticks and.or hubs and using other models. The problem was
reliablew repeatable on all his devices. And we saw it on PowerPC
(MPC5121) and ARM (Kirkwood). That's why I'm pretty sure that it
whill hit if you run such a combo.
> If it is proven to be a bug of a specific device, that would change
> the situation, in that case we would work-around a certain device bug
> that really cannot be solved otherwise. In that case we would _know_
> what problem we are working around, and that would be a limited of
> devices and situations. We at least could document it.
Unfortunately we can only point at the combo of devices - each for
itself appears to be working OK.
> So, I need more info to convince me that this is the right solution.
> Does, for example, Linux have similar issues? If not, why is it
No, we did not observe such problems under Linux. We were not able to
find out why.
> working there. Does a protocol analyser show different behaviour,
> different timing, different data? What is different?
We don't have any such information, unfortunately.
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
Bugs are by far the largest and most successful class of
entity, with nearly a million known species. In this res-
pect they outnumber all the other known creatures about
four to one. -- Professor Snope's Encyclopedia of Animal
More information about the U-Boot
mailing list