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

[Remy Bohmer]

Hi,

2010/11/2 Wolfgang Denk <wd at denx.de>:
> 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.

Hmm, then, unfortunately, you are quite blindfolded for debugging this
problem...

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

As U-boot project-owner you know you have the last word in this.
How do you think how to continue from here?

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

Understood.

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

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.

There should be a difference in controlling the devices triggering the
bug, and without hispeed analyser it will be extremely hard to find.
We have one here, but we do not have your boards, USB hub/devices and
so on. (And... neither do I have the time to debug it for you...)

>> working there. Does a protocol analyser show different behaviour,
>> different timing, different data? What is different?
>
> We don't have any such information, unfortunately.

Understood.

Kind regards,

Remy