Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Subject: Re: [PATCH v2 2/2] USB: core: Attempt power cycle port when it's in
 eSS.Disabled state
From:   Kai-Heng Feng <kai.heng.feng@canonical.com>
In-Reply-To: <c8fc54db-9037-3635-f6a7-d6220e5d02cb@linux.intel.com>
Date:   Tue, 24 Dec 2019 01:32:00 +0800
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        Mathias Nyman <mathias.nyman@intel.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        USB list <linux-usb@vger.kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <9883D946-77E0-4645-89FB-0B61D9E84178@canonical.com>
References: <Pine.LNX.4.44L0.1912111006280.1549-100000@iolanthe.rowland.org>
 <c8fc54db-9037-3635-f6a7-d6220e5d02cb@linux.intel.com>
To:     Mathias Nyman <mathias.nyman@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Dec 17, 2019, at 19:16, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:
> 
> On 11.12.2019 17.08, Alan Stern wrote:
>> On Wed, 11 Dec 2019, Kai-Heng Feng wrote:
>>> 
>>> 
>>>> On Nov 30, 2019, at 01:41, 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 SMSC hub may disconnect after system resume from suspend. When this
>>>> happens, the reset resume attempt fails, and the last resort to disable
>>>> the port and see something comes up later, also fails.
>>>> 
>>>> When the issue occurs, the link state stays in eSS.Disabled state
>>>> despite the warm reset attempts. Accoding to spec this can be caused by
>>>> invalid VBus, after some expiremets, the SMSC hub can be brought back
>>>> after a powercycle.
> 
> Could you open up a bit more how this happens, mainly codepaths how the
> USB3 port ends up in eSS.Disabled state

It happens right after hub_resume(), the first get_port_status():
Dec 23 09:46:58 u-XPS-13-9370 kernel: usb usb4: usb resume
Dec 23 09:46:58 u-XPS-13-9370 kernel: hub 4-0:1.0: hub_resume
Dec 23 09:46:58 u-XPS-13-9370 kernel: xhci_hcd 0000:3f:00.0: Get port status 4-1 read: 0x280, return 0x280
Dec 23 09:46:58 u-XPS-13-9370 kernel: usb usb4-port1: status 0280 change 0000
Dec 23 09:46:58 u-XPS-13-9370 kernel: xhci_hcd 0000:3f:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0
Dec 23 09:46:58 u-XPS-13-9370 kernel: xhci_hcd 0000:3f:00.0: Get port status 4-1 read: 0x280, return 0x280
Dec 23 09:46:58 u-XPS-13-9370 kernel: xhci_hcd 0000:3f:00.0: Get port status 4-1 read: 0x280, return 0x280
Dec 23 09:46:58 u-XPS-13-9370 kernel: xhci_hcd 0000:3f:00.0: Get port status 4-1 read: 0x280, return 0x280

And it keeps getting 0x280. It should mean PP = 1 and PLS = 4, so it's in Disabled state.

> 
> There might be something else wrong here.
> My impression is that port should only end up in eSS.Disabled when directed
> to with a Set_Port_Feature(PORT_LINK_STATE, eSS.Disabled) Request.
> After this we shouldn't attempt warm resets, they won't work for USB3 ports in
> ss.Disabled state.

Do you suggest that we should power cycle the port in xHCI instead of USB core?

Kai-Heng

> 
> -Mathias