[U-Boot] usb start hangs

[york sun]

On 01/05/2017 06:19 PM, Marek Vasut wrote:
> On 01/06/2017 03:13 AM, Tony O'Brien wrote:
>> Hi -
>>
>>
>> We recently updated our U-Boot release to v2016.11 and now our USB devices don't work.  When usb start is executed with a device inserted it hangs at 'scanning bus 0 for devices...' and doesn't recover.  Our product uses an NXP T2081 and I can reproduce this issue on the T2080RDB development board using the tip of U-Boot.  For testing I am using both an EMTEC 16GB USB thumb drive and an Edimax Fast Ethernet adapter.  The code always hangs at drivers/usb/host/ehci-hcd.c:557 in ehci_submit_async, just before the call to handshake.
>>
>>
>> I have traced the issue to 'Commit cb1629f91a48 powerpc: Disable flush or invalidate dcache by range for some SoCs', which is prior to the v2016.07 release.  Commit ac337168ad81 mentioned in this patch removes the original empty functions for the MPC85xx (and others), allowing the functions to be used, but I don't know how they would have worked before this.
>>
>>
>> Either reverting cb1629f91a48 or adding '|| defined(MPC85xx) ' to the #if statements makes usb work again.
>>
>>
>> diff --git a/arch/powerpc/lib/ppccache.S b/arch/powerpc/lib/ppccache.S
>> index 66cf02dbd0..ad28c7c369 100644
>> --- a/arch/powerpc/lib/ppccache.S
>> +++ b/arch/powerpc/lib/ppccache.S
>> @@ -65,7 +65,7 @@ ppcSync:
>>  * flush_dcache_range(unsigned long start, unsigned long stop)
>>  */
>> _GLOBAL(flush_dcache_range)
>> -#if defined(CONFIG_4xx) || defined(CONFIG_MPC86xx)
>> +#if defined(CONFIG_4xx) || defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
>>        li      r5,L1_CACHE_BYTES-1
>>        andc    r3,r3,r5
>>        subf    r4,r3,r4
>> @@ -89,7 +89,7 @@ _GLOBAL(flush_dcache_range)
>>  * invalidate_dcache_range(unsigned long start, unsigned long stop)
>>  */
>> _GLOBAL(invalidate_dcache_range)
>> -#if defined(CONFIG_4xx) || defined(CONFIG_MPC86xx)
>> +#if defined(CONFIG_4xx) || defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
>>        li      r5,L1_CACHE_BYTES-1
>>        andc    r3,r3,r5
>>        subf    r4,r3,r4
>>
>> Do you have any thoughts on this before I submit the patch?
>
> Seems like the right thing to do, but I'd like York to double-check this.
>

Tony,

I put in commit cb1629f91a48 for a very similar reason. Those flushing 
functions were no-op for 85xx. After commit ac337168a, the extra 
flushing made things worse. I don't quite remember which drivers broke 
but I had to exclude 85xx from those function. The code looks correct 
though. Without further information, I cannot reject your idea to enable 
these functions for 85xx. But I am afraid we will see something broken 
again.

York