On 22.4.2020 16.21, Kai-Heng Feng wrote:
>
>
>> On Mar 26, 2020, at 19:33, Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> wrote:
>>
>> Hi Mathias,
>>
>>> On Mar 11, 2020, at 12:04, 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 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?
Was there a request to set port feature, link state to SS.Disabled?
Or timeouts at resume from U3
U3 -> Recovery (timeout) -> Rx.Detect -> Polling (Timeout) -> SS.Disabled
>>>
>>> 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
>>>
>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx>
>>
>> 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?
Any other logs or traces that could explan what's going on?
Is the resume due to a wakeup (device initiated resume) from this device,
or just a host initiated resume?
Thanks
-Mathias
