[U-Boot] usb: Fail to get descriptor for USB 2.0 device

[DATACOM - Paulo.Zaneti]

On 24/05/2018 14:57, Marek Vasut wrote:
> On 05/24/2018 06:23 PM, DATACOM - Paulo.Zaneti wrote:
>>
>> On 23/05/2018 20:40, Bin Meng wrote:
>>> Hi,
>>>
>>> On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zaneti
>>> <paulo.zaneti at datacom.com.br> wrote:
>>>> On 23/05/2018 15:00, Marek Vasut wrote:
>>>>> On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
>>>>>> On 23/05/2018 14:43, Marek Vasut wrote:
>>>>>>> On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
>>>>>>>> On 23/05/2018 14:03, Marek Vasut wrote:
>>>>>>>>> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
>>>>>>>>>> Hi,
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>> When trying to migrate a board from u-boot version 2016.09 to
>>>>>>>>>> version
>>>>>>>>>> 2018.03, I found a problem with a USB 2.0 device which used to
>>>>>>>>>> work
>>>>>>>>>> on
>>>>>>>>>> version 2016.09.
>>>>>>>>> Does it still happen in u-boot/master ?
>>>>>>>> Yes, it still happens.
>>>>>>>>
>>>>>>>> I just tested it with the following commit:
>>>>>>>> dca268a .travis.yml: Further optimizations
>>>>>>>>>> In u-boot version 2016.09 the device appears like this:
>>>>>>>>>>
>>>>>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>>>>>>       - SanDisk Cruzer Blade 200443243002FB509E64
>>>>>>> Let me guess, is this a DWC2-based host ? You didn't mention which
>>>>>>> SoC
>>>>>>> or USB controller it is.
>>>>>>>
>>>>>>> Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
>>>>>>> DWC2 has problems with those sandisk sticks.
>>>>>> No, it is a NXP T1024 SoC.
>>>>>> Do you think it may be a problem with the SoC or NXP USB host driver ?
>>>>>>
>>>>> So that's chipidea ? That one should be reasonably sane.
>>>> I don't think so. It uses following drivers:
>>>>     drivers/usb/host/ehci-fsl.c
>>>>     drivers/usb/host/ehci-hcd.c
>>>>
>>>>> Submit the patch you had in mind and let's see what happens.
>>>> I just noticed that this stick needs more time after the
>>>> usb_set_address()
>>>> call.
>>>> I increased the mdelay(10) to mdelay(20) and the "usb start" command
>>>> worked.
>>>> But the problem is that I am still not convinced that this should be the
>>>> solution.
>>>>
>>> Agreed. Can you bisect to see which commit broke your stick?
>> Yes. The commit which broke my stick is:
>>
>> commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2
>> Author: Bin Meng <bmeng.cn at gmail.com>
>> Date:   Mon Sep 18 06:40:42 2017 -0700
>>
>>      usb: Only get 64 bytes device descriptor for full speed devices
>>
>>
>> My first guess was that this commit should be adapted to
>> "get_descriptor_len()" for USB_SPEED_HIGH too.
>>
>> But then, I realized that I can bypass this problem by increasing the
>> mdelay() after usb_set_address() from 10 to 20 msec.
>>
>> So, I think commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 is not the
>> offender one. It probably uncovered another problem with this stick.
> That particular lineup of sandisk sticks is trash, I have a few of those
> here for testing too.
>
>> I will try to get a better understanding before submitting a patch.
> Did usb_pgood_delay help ?
Yes. It worked. Thanks for the tip.
>