[U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request

[Chin Liang See <clsee@altera.com>]

On Wed, 2016-05-04 at 09:41 +0200, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
> > Some devices, like the SanDisk Cruzer Pop need some time to process
> > the Set Configuration request, so wait a little until they are
> > ready.
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Chin Liang See <clsee@altera.com>
> > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > Cc: Hans de Goede <hdegoede@redhat.com>
> > Cc: Stefan Roese <sr@denx.de>
> > Cc: Stephen Warren <swarren@nvidia.com>
> > ---
> >   common/usb.c | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/common/usb.c b/common/usb.c
> > index 63429d4..205041b 100644
> > --- a/common/usb.c
> > +++ b/common/usb.c
> > @@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device
> > *dev)
> >   			"len %d, status %lX\n", dev->act_len, dev
> > ->status);
> >   		return err;
> >   	}
> > +
> > +	/*
> > +	 * Wait until the Set Configuration request gets processed
> > by the
> > +	 * device. This is required by at least SanDisk Cruzer Pop
> > USB 2.0
> > +	 * and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG
> > controller.
> > +	 */
> > +	mdelay(10);
> > +
> >   	debug("new device strings: Mfr=%d, Product=%d,
> > SerialNumber=%d\n",
> >   	      dev->descriptor.iManufacturer, dev
> > ->descriptor.iProduct,
> >   	      dev->descriptor.iSerialNumber);
> > 
> 
> As you might have expected, I'm not a fan of adding new delays to
> the common USB code. As this negatively affects all platforms. Did
> you test these two sticks that require this delay on other platforms
> than SoCFPGA? I would be very interested to know, if these keys are
> successfully detected without this patch on other platforms. I
> don't have access to these USB keys, so I can't test it on my
> platforms.
> 

Actually this series of patches (include the delay) help for all my
problematic pen drives too. It sound to me these pen drives need time
to process. But at same time, its strange to me that the device didn't
NAK (as I added printout for NAK) to indicate that its busy.

Seems that this issue is noticed at Freescale too. 
http://lists.denx.de/pipermail/u-boot/2015-December/238434.html. Cc'ed
them as they might can share more details on this.

Chin Liang



> Thanks,
> Stefan