[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