Re: [PATCH v2 2/2] USB: core: Attempt power cycle port when it's in eSS.Disabled state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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

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.

-Mathias



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux