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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR04MB12624956F5B6544A78AB1251E9370@VI1PR04MB1262.eurprd04.prod.outlook.com>
Date:   Mon, 11 Dec 2017 08:27:16 +0000
From:   Yinbo Zhu <yinbo.zhu@....com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        "open list:DESIGNWARE USB3 DRD IP DRIVER" <linux-usb@...r.kernel.org>,
        "open list:DESIGNWARE USB3 DRD IP DRIVER" 
        <linux-omap@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Xiaobo Xie <xiaobo.xie@....com>,
        Jerry Huang <jerry.huang@....com>,
        Ran Wang <ran.wang_1@....com>
Subject: RE: [PATCH v2] usb: host: Implement workaround for Erratum A-009611



-----Original Message-----
From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org] 
Sent: Monday, December 11, 2017 3:35 PM
To: Yinbo Zhu <yinbo.zhu@....com>
Cc: Felipe Balbi <felipe.balbi@...ux.intel.com>; Mathias Nyman <mathias.nyman@...el.com>; open list:DESIGNWARE USB3 DRD IP DRIVER <linux-usb@...r.kernel.org>; open list:DESIGNWARE USB3 DRD IP DRIVER <linux-omap@...r.kernel.org>; open list <linux-kernel@...r.kernel.org>; Xiaobo Xie <xiaobo.xie@....com>; Jerry Huang <jerry.huang@....com>; Ran Wang <ran.wang_1@....com>
Subject: Re: [PATCH v2] usb: host: Implement workaround for Erratum A-009611

On Mon, Dec 11, 2017 at 03:15:37AM +0000, Yinbo Zhu wrote:
> 
> 
> -----Original Message-----
> From: Felipe Balbi [mailto:felipe.balbi@...ux.intel.com]
> Sent: Friday, December 08, 2017 6:44 PM
> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; Yinbo Zhu 
> <yinbo.zhu@....com>
> Cc: Mathias Nyman <mathias.nyman@...el.com>; open list:DESIGNWARE USB3 
> DRD IP DRIVER <linux-usb@...r.kernel.org>; open list:DESIGNWARE USB3 
> DRD IP DRIVER <linux-omap@...r.kernel.org>; open list 
> <linux-kernel@...r.kernel.org>; Xiaobo Xie <xiaobo.xie@....com>; Jerry 
> Huang <jerry.huang@....com>; Ran Wang <ran.wang_1@....com>
> Subject: Re: [PATCH v2] usb: host: Implement workaround for Erratum 
> A-009611
> 
> 
> >Hi,
> 
> >Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
> > On Fri, Dec 08, 2017 at 05:49:41PM +0800, yinbo.zhu@....com wrote:
> >> From: "yinbo.zhu" <yinbo.zhu@....com>
> >> 
> >> 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.  

>I do not understand what this means, please explain it a bit better.

>thanks,

>greg k-h

Maybe I have a problem with your words, Your meaning is that you want to ask me why I didn't add an attribute in the device tree to match kernel for every platform, right?