[SRU] [B/D/E/Unstable/OEM-B/OEM-OSP1-B] [PATCH 0/2] Fix unusable USB hub on Dell TB16 after S3

Kai-Heng Feng kai.heng.feng at canonical.com
Wed Dec 11 14:29:35 UTC 2019



> On Dec 11, 2019, at 22:18, Kleber Souza <kleber.souza at canonical.com> wrote:
> 
> On 2019-12-11 15:15, Kai-Heng Feng wrote:
>> 
>> 
>>> On Dec 11, 2019, at 19:16, Kleber Souza <kleber.souza at canonical.com> wrote:
>>> 
>>> On 2019-12-11 10:07, Kai-Heng Feng wrote:
>>>> 
>>>> 
>>>>> On Dec 11, 2019, at 17:03, Kleber Souza <kleber.souza at canonical.com> wrote:
>>>>> 
>>>>> On 2019-12-05 18:05, Kai-Heng Feng wrote:
>>>>>> BugLink: https://bugs.launchpad.net/bugs/1855312
>>>>>> 
>>>>>> [Impact]
>>>>>> Sometimes USB hub on Dell TB16 stop working after S3.
>>>>>> 
>>>>>> [Fix]
>>>>>> Attempt to power cycle USB device when a it's stuck at eSS.Disabled
>>>>>> state, it's basically not recoverable. 
>>>>>> 
>>>>>> [Test]
>>>>>> After applying the patch, USB ports and USB ethernet are still working
>>>>>> after 100 times S3 stress test.
>>>>>> 
>>>>>> [Regression Potential]
>>>>>> Low. This is a last resort attempt, in most cases this code path won't
>>>>>> be reached.
>>>>>> 
>>>>>> Kai-Heng Feng (2):
>>>>>> UBUNTU: SAUCE: USB: core: Make port power cycle a seperate helper
>>>>>>  function
>>>>>> UBUNTU: SAUCE: USB: core: Attempt power cycle port when it's in
>>>>>>  eSS.Disabled state
>>>>>> 
>>>>>> drivers/usb/core/hub.c  | 46 +++++++++++++++++++++++++++++++++++------
>>>>>> drivers/usb/core/hub.h  |  3 +--
>>>>>> drivers/usb/core/port.c |  4 ++--
>>>>>> 3 files changed, 43 insertions(+), 10 deletions(-)
>>>>>> 
>>>>> 
>>>>> Hi Kai-Heng,
>>>>> 
>>>>> The fix is targeted to Unstable so I assume this affects mainline as
>>>>> well. Are we going to try to upstream this fix?
>>>> 
>>>> Yes. I've been poking upstream many times but there's no response.
>>>> This fix is quite crucial to TB16 so we still need this in our kernel.
>>>> 
>>>> Kai-Heng
>>>> 
>>> 
>>> Although you mentioned this code path is a last resort and won't be executed
>>> in most of the cases, this touches the USB core code and the patches don't 
>>> look trivial. So I would like to get some more info about any regression
>>> tests we have executed on other platforms other than the affected one.
>> 
>> Yes I did test on other platforms and didn't observe any regression.
>> 
>> However, I have never seen any other USB device stuck in eSS.Disabled state,
>> so the code path wasn't executed at all.
> 
> Thanks for the feedback. Could you please add this info to the SRU template
> on the bug report?
> 

Of course. It's done.

Kai-Heng

> Thanks!
> 




More information about the kernel-team mailing list