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

Kleber Souza kleber.souza at canonical.com
Wed Dec 11 14:18:57 UTC 2019


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?

Thanks!




More information about the kernel-team mailing list