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

[Remy Bohmer]

Hi Wolfgang,

2010/11/2 Wolfgang Denk <wd at denx.de>:
> Dear Remy Bohmer,
>
> In message <AANLkTikqEFtB=XEAV1G6xyvOY3HW3imCPiFiLD0kVoG6 at mail.gmail.com> you wrote:
>>
>> > +       if (dev->descriptor.idVendor == 0x930 &&
>> > +           dev->descriptor.idProduct == 0x6545 &&
>> > +           dev->parent->descriptor.idVendor == 0x424 &&
>> > +           dev->parent->descriptor.idProduct == 0x2514)
>> > +               wait_ms(10);
>> > +
>>
>> I have to say that I have a problem with this construction.
>> This will solve only 1 particular situation where the user has exactly
>> this USB stick and exactly this hub.
>> If he uses another hub, he can have the same problem. If he use
>> another USB-stick he also can run into this problem.
>> What is the real cause of this issue, and can it be solved in a
>> generic way? I feel the problem is still not understood.
>
> Indeed the problem is not exactly understood.
>
> Anatolij has tested a wide range of board / hub / stick combinations,
> and the problem happens only with this very combination.
>
> Yes, there is a chance that another hub / stick combination might show
> similar issues, but so far we have not been able to find such another
> combo.
>
>> So, I NAK this patch.. Sorry...
>
> So what do you propose to solve the problem?  Of course we could add
> the delay unconditionally, for all systems.  But it brings with it a
> performance degradation which I would not like to see either.

Agreed

> What do you suggest to provide a solution for this specific situation?

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.

But anyway: You admit that the problem is not understood, so would the
delay fix the problem, or just make it less obvious?

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.

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...

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.

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
working there. Does a protocol analyser show different behaviour,
different timing, different data? What is different?


Kind regards,

Remy