All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
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>
Subject: Re: [PATCH v2 2/2] USB: core: Attempt power cycle port when it's in eSS.Disabled state
Date: Tue, 24 Dec 2019 01:32:00 +0800	[thread overview]
Message-ID: <9883D946-77E0-4645-89FB-0B61D9E84178@canonical.com> (raw)
In-Reply-To: <c8fc54db-9037-3635-f6a7-d6220e5d02cb@linux.intel.com>



> 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


      reply	other threads:[~2019-12-23 17:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 17:41 [PATCH v2 1/2] USB: core: Make port power cycle a seperate helper function Kai-Heng Feng
2019-11-29 17:41 ` [PATCH v2 2/2] USB: core: Attempt power cycle port when it's in eSS.Disabled state Kai-Heng Feng
2019-12-11 13:45   ` Kai-Heng Feng
2019-12-11 15:08     ` Alan Stern
2019-12-17 11:16       ` Mathias Nyman
2019-12-23 17:32         ` Kai-Heng Feng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9883D946-77E0-4645-89FB-0B61D9E84178@canonical.com \
    --to=kai.heng.feng@canonical.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.