Thread (5 messages) flat view 5 messages, 4 authors, 2021-06-28

Re: PHY vs. MAC ethtool Wake-on-LAN selection

From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-06-27 17:06:51

- Ethernet MAC (bcmgenet) is capable of doing Wake-on-LAN using Magic
Packets (g) with password (s) or network filters (f) and is powered on in
the "standby" (as written in /sys/power/state) suspend state, and completely
powered off (by hardware) in the "mem" state

- Ethernet PHY (broadcom.c, no code there to support WoL yet) is capable of
doing Wake-on-LAN using Magic Packets (g) with password (s) or a 48-bit MAC
destination address (f) match allowing us to match on say, Broadcom and
Multicast. That PHY is on during both the "standby" and "mem" suspend states
Marvell systems are similar. The mvneta hardware has support for WOL,
and has quite a capable filter. But there is no driver support. WOL is
simply forwarded to the PHY.
What I envision we could do is add a ETHTOOL_A_WOL_DEVICE u8 field and have
it take the values: 0 (default), 1 (MAC), 2 (PHY), 3 (both) and you would do
the following on the command line:

ethtool -s eth0 wol g # default/existing mode, leave it to the driver
ethtool -s eth0 wol g target mac # target the MAC only
ethtool -s eth0 wol g target phy # target the PHY only
ethtool -s eth0 wol g target mac+phy # target both MAC and PHY
This API seems like a start, but is it going to be limiting? It does
not appear you can say:

ethtool -s eth0 wol g target phy wol f target mac

So make use of magic packet in the PHY and filtering in the MAC.
ETHTOOL_A_WOL_DEVICE u8 appears to apply to all WoL options, not one
u8 per option.

And does mac+phy mean both will generate an interrupt? I'm assuming
the default of 0 means do whatever undefined behaviour we have now. Do
we need another value, 4 (auto) and the MAC driver will first try to
offload to the PHY, and if that fails, it does it at the MAC, with the
potential for some options to be in the MAC and some in the PHY?
Is that over engineering or do you see other platforms possibly needing that
distinction?
The over engineering question is clearly valid. Do we actually need to
support all possible options? I've made little use of WoL, so i don't
think i can answer that question.

Also, when it comes to implementation, i would suggest trying to pull
the interpretation of target and decision for MAC or PHY out into
helpers. The complexity is quite high, and if we want uniform
implementation, we want one implementation of it.

	Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help