[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <123BCB7F-5ABA-4DDD-9599-46D3240903F6@canonical.com>
Date: Thu, 3 Oct 2019 19:55:06 +0800
From: Kai-Heng Feng <kai.heng.feng@...onical.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: mathias.nyman@...el.com, gregkh@...uxfoundation.org,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "usb: Avoid unnecessary LPM enabling and disabling
during suspend and resume"
> On Oct 2, 2019, at 23:47, Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Wed, 2 Oct 2019, Kai-Heng Feng wrote:
>
>> This reverts commit d590c23111505635e1beb01006612971e5ede8aa.
>>
>> Dell WD15 dock has a topology like this:
>> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
>> |__ 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
>>
>> Their IDs:
>> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 004 Device 002: ID 0424:5537 Standard Microsystems Corp.
>> Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp.
>>
>> Ethernet cannot be detected after plugging ethernet cable to the dock,
>> the hub and roothub get runtime resumed and runtime suspended
>> immediately:
>> ...
>
>> After some trial and errors, the issue goes away if LPM on the SMSC hub
>> is disabled. Digging further, enabling and disabling LPM during runtime
>> resume and runtime suspend respectively can solve the issue.
>>
>> So bring back the old LPM behavior, which the SMSC hub inside Dell WD15
>> depends on.
>>
>> Fixes: d590c2311150 ("usb: Avoid unnecessary LPM enabling and disabling during suspend and resume")
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
>
> Maybe it would be better to have a VID/PID-specific quirk for this?
Re-reading the spec, I think we need some clarification:
"If the value is 3, then host software wants to selectively suspend the
device connected to this port. The hub shall transition the link to U3
from any of the other U states using allowed link state transitions.
If the port is not already in the U0 state, then it shall transition the
port to the U0 state and then initiate the transition to U3."
The phrase "then it shall transition the port to the U0 state" what does "it" here refer to?
Is it the hub or the software?
If it's the former then it's indeed a buggy hub, but if it's the latter I think reverting the commit is the right thing to do.
Kai-Heng
>
> Alan Stern
>
Powered by blists - more mailing lists