linux-kernel - Re: [PATCH v4] fsl/usb: Workarourd for USB erratum-A005697

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 30 Nov 2016 10:22:44 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Changming Huang <jerry.huang@....com>
cc:     gregkh@...uxfoundation.org, <ramneek.mehresh@....com>,
        <sriram.dash@....com>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] fsl/usb: Workarourd for USB erratum-A005697

On Tue, 29 Nov 2016, Changming Huang wrote:

> The EHCI specification states the following in the SUSP bit description:
> In the Suspend state, the port is sensitive to resume detection.
> Note that the bit status does not change until the port is suspended and
> that there may be a delay in suspending a port if there is a transaction
> currently in progress on the USB.
> 
> However, in NXP USBDR controller, the PORTSCx[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 make sure this port has entered
> suspended state before initiating this port resume using the Force Port
> Resume bit. This bit is for NXP controller, not EHCI compatible.
> 
> Signed-off-by: Changming Huang <jerry.huang@....com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@....com>
> ---
> Changes in v4:
>   - release spinlock before sleeping
> Changes in v3:
>   - add 10ms delay in function ehci_hub_control
>   - fix typos
> Changes in v2:
>   - move sleep out of spin-lock
>   - add more comment for this workaround

Acked-by: Alan Stern <stern@...land.harvard.edu>