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

On 6/27/2021 12:09 PM, Russell King (Oracle) wrote:

On Sun, Jun 27, 2021 at 07:06:45PM +0200, Andrew Lunn wrote:

quoted

quoted

- 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.

quoted

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?

Another question concerns the capabilities of the MAC and PHY in each
low power mode. Consider that userspace wishes to program the system
to wakeup when a certain packet is received. How does it know whether
it needs to program that into the MAC or the PHY or both?

There is no way right now to know other than just having user-space be 
customized to the desired platform which is something that works 
reasonably well for Android, not so much for other distros.

Should that level of detail be available to userspace, or kept within
the driver?

For example, if userspace requests destination MAC address wakeup, then
shouldn't the driver be making the decision about which of the MAC or
PHY gets programmed to cause the wakeup depending on which mode the
system will be switching to and whether the appropriate blocks can be
left powered?

Another question would be - if the PHY can only do magic packet and
remains powered, and the MAC can only do destination MAC but is powered
down in the "mem" state, what do we advertise to the user. If the user
selects destination MAC and then requests the system enter "mem" state,
then what? Should we try to do the best we can?

This is the part where it may be reasonable to lean on to user-space to 
program either the MAC or the PHY in a way that makes sense to support a 
Wake-on-LAN scheme, whether that means that ethtool should also report 
which modes are supported depending on the target system suspend such 
that user-space has information to make an appropriate decision may just 
be the next step.

Should we at the very least be advertising which WOL modes are
supported in each power state?

It would make sense to do that, I do wonder if the reporting may be more 
complicated in case there are device-specific power domains that we need 
to be aware of, instead of just a report per PM_SUSPEND_* mode defined 
in include/linux/suspend.h.
-- 
Florian