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] [day] [month] [year] [list]
Date:   Fri, 25 Nov 2016 02:52:48 +0000
From:   Jerry Huang <jerry.huang@....com>
To:     Alan Stern <stern@...land.harvard.edu>,
        Sriram Dash <sriram.dash@....com>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "julia.lawall@...6.fr" <julia.lawall@...6.fr>,
        Ramneek Mehresh <ramneek.mehresh@....com>,
        Suresh Gupta <suresh.gupta@....com>
Subject: RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697

Hi, Alan,
Maybe other USB controller does not need this delay. 
However, our silicon errata point out,  in the USBDR controller, the PORTCx[SUSP] bit changes immediately when the application sets it and not when the port is actually suspended, so the application must wait for at least 10 milliseconds after a port indicates that it is suspended to ensure the port has entered SUSPEND status before initiating this port resume using the Force Port Resume (which is one bit for NXP silicon, not-EHCI compatible).
I will add more comment to understand why we need this delay in next version.

Best Regards
Jerry Huang


-----Original Message-----
From: Alan Stern [mailto:stern@...land.harvard.edu] 
Sent: Friday, November 25, 2016 12:54 AM
To: Sriram Dash <sriram.dash@....com>
Cc: Jerry Huang <jerry.huang@....com>; gregkh@...uxfoundation.org; linux-usb@...r.kernel.org; linux-kernel@...r.kernel.org; julia.lawall@...6.fr; Ramneek Mehresh <ramneek.mehresh@....com>; Suresh Gupta <suresh.gupta@....com>
Subject: RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697

On Thu, 24 Nov 2016, Sriram Dash wrote:

> >From: Changming Huang [mailto:jerry.huang@....com] As per USB 
> >specification, in the Suspend state, the status bit does not change 
> >until the port is suspended. However, there may be a delay in 
> >suspending a port if there is a transaction currently in progress on the bus.
> >
> >In the USBDR controller, the PORTSCx[SUSP] bit changes immediately 
> >when the application sets it and not when the port is actually 
> >suspended
> >
> >Workaround for this issue involves waiting for a minimum of 10ms to 
> >allow the controller to go into SUSPEND state before proceeding ahead

The USB core guarantees that there won't be any data transactions in progress when a root hub is suspended.  There might possibly be an SOF transaction, but that doesn't take more than a few microseconds at most.  Certainly nowhere near 10 ms!

Given that we already perform a 150-us delay, is this change really needed?

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ