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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <580F5704.7030605@linux.intel.com>
Date:   Tue, 25 Oct 2016 15:58:44 +0300
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Sriram Dash <sriram.dash@....com>, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Cc:     mathias.nyman@...el.com, gregkh@...uxfoundation.org,
        suresh.gupta@....com, felipe.balbi@...ux.intel.com,
        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

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?
Is there some device that is in resume (PLS==XDEV_RESUME) while driving reset?

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

-Mathias