linux-kernel - Re: [PATCH] usb: host: xhci: Avoid XHCI resume delay if SSUSB device is not present

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]

Message-ID: <c22e7751-0367-a7e6-1fa5-c5afe5df7808@linux.intel.com>
Date:   Fri, 28 Apr 2023 13:17:10 +0300
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Wesley Cheng <quic_wcheng@...cinc.com>, mathias.nyman@...el.com,
        gregkh@...uxfoundation.org
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] usb: host: xhci: Avoid XHCI resume delay if SSUSB device
 is not present

On 27.4.2023 22.01, Wesley Cheng wrote:
> There is a 120ms delay implemented for allowing the XHCI host controller to
> detect a U3 wakeup pulse.  The intention is to wait for the device to retry
> the wakeup event if the USB3 PORTSC doesn't reflect the RESUME link status
> by the time it is checked.  As per the USB3 specification:
> 
>    tU3WakeupRetryDelay ("Table 7-12. LTSSM State Transition Timeouts")
> 
> This would allow the XHCI resume sequence to determine if the root hub
> needs to be also resumed.  However, in case there is no device connected,
> or if there is only a HSUSB device connected, this delay would still affect
> the overall resume timing.
> 
> Since this delay is solely for detecting U3 wake events (USB3 specific)
> then ignore this delay for the disconnected case and the HSUSB connected
> only case.
> 
> Signed-off-by: Wesley Cheng <quic_wcheng@...cinc.com>
> ---
>   drivers/usb/host/xhci.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 78790dc13c5f..7a86cd683502 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -834,7 +834,8 @@ static bool xhci_pending_portevent(struct xhci_hcd *xhci)
>   	while (port_index--) {
>   		portsc = readl(ports[port_index]->addr);
>   		if (portsc & PORT_CHANGE_MASK ||
> -		    (portsc & PORT_PLS_MASK) == XDEV_RESUME)
> +		    (portsc & PORT_PLS_MASK) == XDEV_RESUME ||
> +		    !(portsc & PORT_CONNECT))
>   			return true;
This change will report a pending port event at the first empty roothub port.

I think we are looking for something like this instead (pseudo):

@@ -1116,7 +1116,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
                  * the first wake signalling failed, give it that chance.
                  */
                 pending_portevent = xhci_pending_portevent(xhci);
-               if (!pending_portevent) {
+               if (!pending_portevent && usb3_devices_connected && runtime_resume) {
                         msleep(120);
                         pending_portevent = xhci_pending_portevent(xhci);
                 }

Thanks
Mathias