On Wed, Jul 19, 2023 at 02:36:25PM -0400, Alan Stern wrote:
On Wed, Jul 19, 2023 at 05:37:56PM +0000, Alexandru Gagniuc wrote:
For Wake-on-LAN to work from S5 (shutdown), the USB link must be put in U3 state. If it is not, and the host "disappears", the chip will no longer respond to WoL triggers.
To resolve this, add a notifier block and register it as a reboot notifier. When WoL is enabled, work through the usb_device struct to get to the suspend function. Calling this function puts the link in the correct state for WoL to function.
How do you know that the link will _remain_ in the correct state?
The objective is to get to xhci_set_link_state() with the USB_SS_PORT_LS_U3 argument. This is achieved through usb_port_suspend() in drivers/usb/host/hub.c, and the function is implemented in drivers/usb/host/xhci-hub.c.
This is the only path in the kernel that I am aware of for setting the U3 link state. Given that it is part of the USB subsystem, I am fairly confident it will show consistent behavior across platforms.
That is, how do you know that the shutdown processing for the USB host controller won't disable the link entirely, thereby preventing WoL from working?
We are talking to the USB hub in order to set the link state. I don't see how specifics of the host controller would influence behavior. I do expect a controller which advertises S4/S5 in /proc/acpi/wakeup to not do anything that would sabotage this capability. Disabling the link entirely would probalby violate that promise.
Think of USB-C docks with a power button showing up as a HID class. The scenario herein would disable the power button. I would take that to be a bug in the host controller driver if the S4/S5 capability is advertised.
Alex
P.S. I sincerely apologize for the delay in my reply. The corporate email servers here have "difficulties" with plaintext and interleaved replies.