Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: [PATCH v2] xhci: Set port link to RxDetect if port is not enabled
 after resume
From:   Kai-Heng Feng <kai.heng.feng@canonical.com>
In-Reply-To: <35fbb517-31b1-7bba-8e07-795ab18af1ff@linux.intel.com>
Date:   Mon, 27 Apr 2020 17:05:47 +0800
Cc:     Mathias Nyman <mathias.nyman@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Alan Stern <stern@rowland.harvard.edu>,
        "open list:USB NETWORKING DRIVERS" <linux-usb@vger.kernel.org>,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8BIT
Message-Id: <47BCEDDA-2E91-4CE3-AA45-B2EEB1DA111D@canonical.com>
References: <20200311040456.25851-1-kai.heng.feng@canonical.com>
 <B4E44BDC-5AFE-4F8A-8498-0EEE9CDAC0E1@canonical.com>
 <635B3350-F064-4B45-B194-40F793423049@canonical.com>
 <35fbb517-31b1-7bba-8e07-795ab18af1ff@linux.intel.com>
To:     Mathias Nyman <mathias.nyman@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Apr 23, 2020, at 19:25, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:
> 
> On 22.4.2020 16.21, Kai-Heng Feng wrote:
>> 
>> 
>>> On Mar 26, 2020, at 19:33, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
>>> 
>>> Hi Mathias,
>>> 
>>>> On Mar 11, 2020, at 12:04, Kai-Heng Feng <kai.heng.feng@canonical.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
> 
> That sound like the actual problem.
> Any idea how the port link ends up ends up in the disabled state?

Not really. The port link status just became SS.Disabled after S3 wakeup.

> Was there a request to set port feature, link state to SS.Disabled? 

No, it was correctly set to U3 prior to system S3.

> Or timeouts at resume from U3
> U3 -> Recovery  (timeout) -> Rx.Detect -> Polling (Timeout) ->  SS.Disabled

PLS is SS.Disabled, by reading portsc in xhci_bus_resume().

> 
>>>> 
>>>> 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.
> 
> Sounds more like re-enumerate than proper resume if we go to RxDetect in between

Ok. So should we handle this case inside xhci_bus_resume() or somewhere else?

> 
>>>> 
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>> 
>>> Do you think this is a proper fix?
>> 
>> Another gentle ping...
>> 
>>> 
>>> 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;
>>>> +		}
>>>> + 
> This doesn't look like the right solution.
> This will set the link state to RxDetect for any USB3 roothub port
> that is currently not in U0/U1/U2/U3 or Recovery.
> 
> Was this roothub port forcefully suspended xhci_bus_suspend()?
> i.e. was a bit set in bus_state->bus_suspended for this port?

No, it's a USB3 device so it was set to U3 via USB_PORT_FEAT_LINK_STATE.

> 
> Any other logs or traces that could explan what's going on?

Read port status in  xhci_bus_resume():
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index f37316d2c8fa..c2e9ac3dc227 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1778,7 +1778,7 @@ int xhci_bus_resume(struct usb_hcd *hcd)
        port_index = max_ports;
        while (port_index--) {
                portsc = readl(ports[port_index]->addr);
-
+               xhci_info(xhci, "DEBUG: port %d-%d, portsc 0x%0x pls %d\n", hcd->self.busnum, port_index + 1, portsc, (portsc & PORT_PLS_MASK) >> 5);
                /* warm reset CAS limited ports stuck in polling/compliance */
                if ((xhci->quirks & XHCI_MISSING_CAS) &&
                    (hcd->speed >= HCD_USB3) &&

Here's the log. The log is not full because it's too big to upload:
https://pastebin.ubuntu.com/p/24hzqx2nGD/

> Is the resume due to a wakeup (device initiated resume) from this device,
> or just a host initiated resume?

It's a host initiated resume.

> 
> Thanks
> -Mathias