On 30.08.22 21:50, jflf_kernel@xxxxxxx wrote: Hi, > TL;DR: the two VL812 hubs don't behave well when suspended. We need to know the exact nature of their transgressions to inflict the correct correctional measures. > I have always kept keyboard and mouse on the USB2 ports connected to the Genesys Logic hub. They work there without any problem. So they work even without your patch? We should make sure we are absolutely clear on details. > With WoL enabled in the BIOS, there are only two wakeup sources: > > $ grep . /sys/bus/usb/devices/*/power/wakeup | grep enabled > /sys/bus/usb/devices/1-6.2.2/power/wakeup:enabled # keyboard on GL850S > /sys/bus/usb/devices/2-1.1.3/power/wakeup:enabled # net > > While suspended I can wake up the laptop with the keyboard and everything works. Again, with or without RESET_RESUME? > Moving the keyboard to one of the VL812 ports moves the wakeup source:: > > $ grep . /sys/bus/usb/devices/*/power/wakeup | grep enabled > /sys/bus/usb/devices/1-6.1.1/power/wakeup:enabled # keyboard on the :1019 VL812 (USB2) > /sys/bus/usb/devices/2-1.1.3/power/wakeup:enabled # net > > > Now here's the interesting bit. Without "usbcore.autosuspend=-1" I can still wakeup the laptop from suspend, but after waking up the keyboard is gone: > > kernel: hub 1-6.1:1.0: hub_ext_port_status failed (err = -71) > kernel: hub 1-6:1.0: hub_ext_port_status failed (err = -71) > kernel: hub 1-6.1:1.0: hub_ext_port_status failed (err = -71) > kernel: hub 1-6.1:1.0: hub_ext_port_status failed (err = -71) > kernel: usb 1-6.1-port4: cannot disable (err = -71) > kernel: usb 1-6.1-port1: cannot disable (err = -71) > > After that the port to which the keyboard is connected is essentially dead. Replugging doesn't help, I need to shutdown the laptop (powered via the dock) and cut all power to the dock to get that port back to operational status. > > With "usbcore.autosuspend=-1", everything behaves as it should. Do the keyboard and the hub suspend? Is this with your patch or without? > 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 Regards Oliver
