RE: [PATCH v2] usb: host: Implement workaround for Erratum A-009611

[Yinbo Zhu]

-----Original Message-----
From: Felipe Balbi [mailto:felipe.balbi@xxxxxxxxxxxxxxx] 
Sent: Friday, December 08, 2017 6:44 PM
To: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Yinbo Zhu <yinbo.zhu@xxxxxxx>
Cc: Mathias Nyman <mathias.nyman@xxxxxxxxx>; open list:DESIGNWARE USB3 DRD IP DRIVER <linux-usb@xxxxxxxxxxxxxxx>; open list:DESIGNWARE USB3 DRD IP DRIVER <linux-omap@xxxxxxxxxxxxxxx>; open list <linux-kernel@xxxxxxxxxxxxxxx>; Xiaobo Xie <xiaobo.xie@xxxxxxx>; Jerry Huang <jerry.huang@xxxxxxx>; Ran Wang <ran.wang_1@xxxxxxx>
Subject: Re: [PATCH v2] usb: host: Implement workaround for Erratum A-009611


>Hi,

>Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> On Fri, Dec 08, 2017 at 05:49:41PM +0800, yinbo.zhu@xxxxxxx wrote:
>> From: "yinbo.zhu" <yinbo.zhu@xxxxxxx>
>> 
>> Description: This is a occasional problem where the software
>
> No need for a "Description:" word.  That's just assumed here, right?

I will remove "Description:" thanks.
>> issues an End Transfer command while a USB transfer is in progress, 
>> resulting in the TxFIFO  being flushed when the lower layer is 
>> waiting for data,causing the super speed (SS) transmit to get blocked.
>> If the End Transfer command is issued on an IN endpoint to flush out 
>> the pending transfers when the same IN endpoint is doing transfers on 
>> the USB, then depending upon the timing of the End Transfer (and the 
>> resulting internal FIFO flush),the lower layer (U3PTL/U3MAC) could 
>> get stuck waiting for data indefinitely. This blocks the transmission 
>> path on the SS, and no DP/ACK/ERDY/DEVNOTIF packets can be sent from 
>> the device.
>> Impact: If this issue happens and the transmission gets blocked, then 
>> the USB host aborts and resets/re-enumerates the device.
>> This unblocks the transmitt engine and the device functions normally.
>> 
>> Workaround: Software must wait for all existing TRBs to complete 
>> before issuing End transfer command.
>> 
>> Configs Affected:
>> LS1088-48A-R1.0, LS2081A-R1.1, LS2088-48A-R1.0, LS2088-48A-R1.1, 
>> LX2160-2120-2080A-R1.
>
> What are these Configs?  That doesn't seem to match up with anything 
> that is in the kernel tree that I can see.

These configs is soc information, I don't enable it on these platform dts.
Although the erratum issue can't be reproduced.  
>> 
>> Signed-off-by: yinbo.zhu <yinbo.zhu@xxxxxxx>
>> ---
>>  drivers/usb/dwc3/core.c      |  3 +++
>>  drivers/usb/dwc3/core.h      |  3 +++
>>  drivers/usb/dwc3/host.c      |  3 +++
>>  drivers/usb/host/xhci-plat.c |  4 ++++
>>  drivers/usb/host/xhci.c      | 24 ++++++++++++++++++------
>>  drivers/usb/host/xhci.h      |  1 +
>>  6 files changed, 32 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 
>> 5cb3f6795b0b..071e7cea8cbb 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1106,6 +1106,9 @@ static void dwc3_get_properties(struct dwc3 
>> *dwc)
>>  
>>  	dwc->quirk_reverse_in_out = device_property_read_bool(dev,
>>  				"snps,quirk_reverse_in_out");

>This was generated on vendor tree. This quirk doesn't exist in dwc3. Also,
 >update your tree and review MAINTAINERS file. It has been almost 2 years since I left TI :-)

>--
>Balbi

Hi Balbi,

The quirk that I had add it in dwc3. Your meaning is that I can't use quirk to enable or disable the erratum, isn't it? The tree is git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git, I had updated it.

Thanks.
Yinbo