linux-kernel - Re: [PATCH] usb: add quirks for Lenovo OneLink+ Dock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0bdfdd52-4e73-0554-ef94-5da5af0ae01b@gmx.com>
Date:   Sun, 4 Sep 2022 23:38:31 +0200
From:   jflf_kernel@....com
To:     Oliver Neukum <oneukum@...e.com>, gregkh@...uxfoundation.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: add quirks for Lenovo OneLink+ Dock

On 31/08/2022 11.16, Oliver Neukum wrote:

>> I'll run some more tests out of curiosity to see how things behave in corner cases.
>
> While you do so, which is a good idea, could you restate your current
> results in a more precise way? We should have 4 results for each hub.
> It is not the case that RESET_RESUME has no effect if you give
> usbcore.autosuspend=-1 if the system has been suspended. Hence we have
> the cases of
>
> no RESET_RESUME/default autosuspend
> no RESET_RESUME/autosuspend=-1
> with RESET_RESUME/default autosuspend
> with RESET_RESUME/autosuspend=-1

Hi Oliver,

Apologies for my last unclear message.

Both VL812 hubs behave the same way so I have a single table for both. The settings are applied to both hubs, on both USB2 and USB3.

I have separated USB2 and USB3 as they behave slightly differently.

=======================================================================================
Settings                        USB2 hotplug    USB3 hotplug    State after waking up
---------------------------------------------------------------------------------------

power/control=auto              works (1)       fails           broken (2)

usbcore.autosuspend=-1          works           works           broken (2)
OR power/control=on

power/control=auto              works (3)       works (3)       works
and USB_QUIRK_RESET_RESUME

power/control=on                works           works           works
and USB_QUIRK_RESET_RESUME

HUB_QUIRK_DISABLE_AUTOSUSPEND   works           works           works
and USB_QUIRK_RESET_RESUME

=======================================================================================

(1) I have yet to find a device that would be rejected by the USB2 side, while I have reliable reproducers for USB3. The problem appears with specific devices only, which otherwise work flawlessly on other hubs, other systems, etc.

(2) After a system wake-up the hubs are in a seemingly random state. Numerous errors appear in the syslog, and some ports may be dead (changes from wake-up to wake-up). This can affect both internal (to dock built-in devices) and external hub ports.

(3) With RESET_RESUME the hubs (both USB2 and USB3) stay active and don't autosuspend, even when power/control==auto.

In all situations above a keyboard and the integrated ethernet controller can wake up the laptop from suspend. In situations (2) they may not work anymore after waking up.

The bottom line is: we need USB_QUIRK_RESET_RESUME to deal with the spurious hub state after waking up, and we need to prevent the hubs from autosuspending to work around the USB3 issue. RESET_RESUME does all of that right now, but can its behaviour be considered stable? Is there any chance that some day it would no longer block autosuspend?

If RESET_RESUME is stable, then my current patch is enough and it can be re-merged. If not, I have an updated patch ready with HUB_QUIRK_DISABLE_AUTOSUSPEND.

Also, RESET_RESUME keeps the device nodes active, but not the hub interface nodes. HUB_QUIRK_DISABLE_AUTOSUSPEND and usbcore.autosuspend=-1 keep both of them active:

    $ grep active /sys/bus/usb/devices/2*/power/runtime_status    # USB_QUIRK_RESET_RESUME
    /sys/bus/usb/devices/2-1.1/power/runtime_status:active
    /sys/bus/usb/devices/2-1/power/runtime_status:active

    $ grep active /sys/bus/usb/devices/2*/power/runtime_status    # HUB_QUIRK_DISABLE_AUTOSUSPEND
    /sys/bus/usb/devices/2-1:1.0/power/runtime_status:active
    /sys/bus/usb/devices/2-1.1:1.0/power/runtime_status:active
    /sys/bus/usb/devices/2-1.1/power/runtime_status:active
    /sys/bus/usb/devices/2-1/power/runtime_status:active

I do not know what impact this could have. In my tests both accepted the hotplugged USB3 devices, so keeping the device nodes active is enough.

Thanks!
JF