[U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Marek Vasut <marex@denx.de>]

On 06/22/2016 08:36 AM, Rajesh Bhagat wrote:
> 
> 
> From: Matthew Bright [mailto:Matthew.Bright at alliedtelesis.co.nz] 
> Sent: Wednesday, June 22, 2016 11:42 AM
> To: Rajesh Bhagat <rajesh.bhagat@nxp.com>; marex at denx.de
> Cc: u-boot at lists.denx.de; Chris Packham <Chris.Packham@alliedtelesis.co.nz>; Mark Tomlinson <Mark.Tomlinson@alliedtelesis.co.nz>
> Subject: testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks
> 
> On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
>> Performs code cleanup by making common function for usb_stor_read/write
>> and implements the logic to calculate the optimal usb maximum trasfer blocks
>> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
>> of EHCI and other USB protocols respectively.
>>  
>> Rajesh Bhagat (3):
>>   common: usb_storage: Make common function for usb_read_10/usb_write_10
>>   common: usb_storage: Make common function for
>>     usb_stor_read/usb_stor_write
>>   common: usb_storage : Implement logic to calculate optimal usb maximum
>>     trasfer blocks
>>  
>>  common/usb_storage.c | 213 +++++++++++++++++++++++----------------------------
>>  include/usb.h        |   1 +
>>  2 files changed, 98 insertions(+), 116 deletions(-)
>>  
>>
>> Hi Rajesh & Marek
>>
>> I have spend the last couple of days testing these patches on the
>> v2016.05 release, with an usb mass storage device that is able to
>> consistently reproduce the USB_MAX_XFER_BLK issue as described in
>> the "Issue with USB mass storage (thumb drives)" u-boot thread.
>>
>> http://lists.denx.de/pipermail/u-boot/2016-February/244464.html?
>>
> 
> Hello Matt, 
> 
>> I can confirm the patch correctly increases the max transfer bocks
>> after a successful read, and decreases the max transfer bocks after
>> a read failure. However, I have noticed that once the ehci time out
>> error occurs, the usb device appears to lock up. When in this state
>> the usb device will stop responding to any further transfers. This
>> behavior is independent of the number of blocks, and will continue
>> until the ehci has been reset.
>>
> 
> I believe the lockup behavior mentioned by you to be device specific quirk. 
> I tested 3 pen drives, which recovered from EHCI timeout behavior by 
> reducing the number of blocks (check below output): 
> 

3 devices is not a representative sample.

-- 
Best regards,
Marek Vasut