Hi Wolfgang,
2010/11/2 Wolfgang Denk wd@denx.de:
Dear Remy Bohmer,
In message AANLkTikqEFtB=XEAV1G6xyvOY3HW3imCPiFiLD0kVoG6@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