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
