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]
Message-ID: <DB5PR0401MB192536FA8EAD160164C924BAF5AB0@DB5PR0401MB1925.eurprd04.prod.outlook.com>
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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ