linux-kernel - Re: [PATCH v2] xhci: Set port link to RxDetect if port is not enabled after resume

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: <B4E44BDC-5AFE-4F8A-8498-0EEE9CDAC0E1@canonical.com>
Date:   Thu, 26 Mar 2020 19:33:26 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Mathias Nyman <mathias.nyman@...el.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stern@...land.harvard.edu, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] xhci: Set port link to RxDetect if port is not enabled
 after resume

Hi Mathias,

> On Mar 11, 2020, at 12:04, Kai-Heng Feng <kai.heng.feng@...onical.com> wrote:
> 
> On Dell TB16, Realtek USB ethernet (r8152) connects to an SMSC hub which
> then connects to ASMedia xHCI's root hub:
> 
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 5000M
>            |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
> 
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 004 Device 002: ID 0424:5537 Standard Microsystems Corp. USB5537B
> Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
> 
> The port is disabled after resume:
> xhci_hcd 0000:3f:00.0: Get port status 4-1 read: 0x280, return 0x280
> 
> According to xHCI 4.19.1.2.1, we should set link to RxDetect to transit
> it from disabled state to disconnected state, which allows the port to
> be set to U0 and completes the resume process.
> 
> My own test shows port can still resume when it's not enabled, as long
> as its link is in U states. So constrain the new logic only when link is
> not in any U state.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>

Do you think this is a proper fix?

Kai-Heng

> ---
> drivers/usb/host/xhci-hub.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index a9c87eb8951e..263f9a9237a1 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1776,6 +1776,14 @@ int xhci_bus_resume(struct usb_hcd *hcd)
> 			clear_bit(port_index, &bus_state->bus_suspended);
> 			continue;
> 		}
> +
> +		/* 4.19.1.2.1 */
> +		if (!(portsc & PORT_PE) && (portsc & PORT_PLS_MASK) > XDEV_U3) {
> +			portsc = xhci_port_state_to_neutral(portsc);
> +			portsc &= ~PORT_PLS_MASK;
> +			portsc |= PORT_LINK_STROBE | XDEV_RXDETECT;
> +		}
> +
> 		/* resume if we suspended the link, and it is still suspended */
> 		if (test_bit(port_index, &bus_state->bus_suspended))
> 			switch (portsc & PORT_PLS_MASK) {
> -- 
> 2.17.1
>