linux-kernel - RE: [PATCH v2] usb: xhci: Don't drive port 2.0 reset while resuming

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Oct 2016 12:34:48 +0000
From:   Sriram Dash <sriram.dash@....com>
To:     Mathias Nyman <mathias.nyman@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
CC:     "mathias.nyman@...el.com" <mathias.nyman@...el.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Suresh Gupta <suresh.gupta@....com>,
        "felipe.balbi@...ux.intel.com" <felipe.balbi@...ux.intel.com>,
        "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
        Rajat Srivastava <rajat.srivastava@....com>,
        Rajesh Bhagat <rajesh.bhagat@....com>
Subject: RE: [PATCH v2] usb: xhci: Don't drive port 2.0 reset while resuming

>From: Mathias Nyman [mailto:mathias.nyman@...ux.intel.com]
>On 25.10.2016 13:45, Sriram Dash wrote:
>> For the USB3.0 controller, USB 2.0 reset not driven while port is in
>> Resume state. So, do not program the USB 2.0 reset
>> (PORTSC[PR]=1) while in Resume state.
>>
>> Signed-off-by: Rajat Srivastava <rajat.srivastava@....com>
>> Signed-off-by: Sriram Dash <sriram.dash@....com>
>> Signed-off-by: Rajesh Bhagat <rajesh.bhagat@....com>
>> ---
>
>What is the actual issue that you are fixing here?

This was an erratum from Synopsis STAR: 9000962562

>Is there some device that is in resume (PLS==XDEV_RESUME) while driving reset?
>

We have not reproduced this as such.

>I just sent a pach for increasing the resume time signaling to 40ms when clearing
>the PORT_FEAT_SUSPEND.
>Does that work for you?
>
>If not, then we should look closer at why clearing the suspend does not work
>properly.
>One issue could be that ClearPortFeature PORT_FEAT_SUSPEND does not really
>read or wait for for changes in port status. It blindly sets the states based on time
>passed.
>
>Or if it's after system suspend there might be something in bus_resume that is not
>working.
>
>I don't think usb core tries to drive reset while port is still resuming
>

I am skeptical about it and hope somebody may help us on this.

>-Mathias
>