Message-ID: <554fea3f-ba7c-b2fc-5ee6-755015f6dfba@gmail.com>
Date:   Sat, 26 Jun 2021 20:53:27 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Linux Netdev List <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vladimir Oltean <olteanv@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Michal Kubecek <mkubecek@...e.cz>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: PHY vs. MAC ethtool Wake-on-LAN selection

Hi all,

I would like to request your feedback on implementing a solution so that 
we can properly deal with choosing PHY or MAC Wake-on-LAN configuration.

The typical use case that I am after is the following: an Android TV box 
which is asleep as often as possible and needs to wake-up when a local 
network device wants to "cast" to the box. This happens when your phone 
does a mDNS query towards a multicast IPv4 address and searches for a 
particular service.

Now, consider the existing system's capabilities:

- system supports both "standby" (as written in /sys/power/state) with 
all the blocks powered on and "mem" with only a subset of the SoC 
powered on (a small always on island and supply)

- 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

The network filtering capability of the Ethernet MAC in the "standby" 
state is superior to that of the Ethernet PHY and would allow for finer 
filtering of the network packets, so it should be preferred when the 
standby state is "standby" so we can limit spurious wake-ups on 
multicast traffic and specifically that not matching the desired 
service. There may also be capability to match on all of "gsf" instead 
of just "g" or "s" so it is preferred.

When the standby state is "mem" however we would want to use the PHY 
because that is the only one in the always-on island that can be active, 
even if it has coarse filtering capabilities.

Since bd8c9ba3b1e2037af5af4e48aea1087212838179 ("PM / suspend: Export 
pm_suspend_target_state") drivers do have the ability to determine which 
suspend state we are about to enter at ->suspend() time, so with the 
knowledge about the system as to which of the MAC or the PHY will remain 
on (using appropriate Device Tree properties for instance: always-on) 
and service Wake-on-LAN, a driver could make an appropriate decision as 
to whether it wants to program the MAC or the PHY with the Wake-on-LAN 
configuration.

The programming of the Wake-on-LAN is typically done at ->suspend() time 
and not necessarily at the time the user is requesting it, and at the 
time the user configures Wake-on-LAN we do not know yet the target 
suspend state.

This is a problem that could be punted to user-space in that it controls 
which suspend mode the system will enter. We could therefore assume that 
user space should know which Wake-on-LAN configuration to apply, even if 
that could mean "double" programming of both the MAC and PHY, knowing 
that the MAC will be off so the PHY will take over. The problem I see 
with that is that approach:

- you must always toggle between Wake-on-LAN programming depending upon 
the system standby mode which may not always be practical

- the behavior can vary wildly between platforms depending upon 
capabilities of the drivers and their bugs^w implementation

- we are still missing the ability to install a specific Wake-on-LAN 
configuration towards the desired MAC or PHY entity

The few drivers that call phy_ethtool_{set,get}_wol() except lan743x do 
not actually support Wake-on-LAN at the MAC level, so that is an easy 
decision to make for them because it is the only way they can support 
Wake-on-LAN.

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

Is that over engineering or do you see other platforms possibly needing 
that distinction? Heiner, how about r8169, are there similar constraints 
with respect to which part of the controller is on/off during S2, S3 or S5?

Thanks!
-- 
Florian

Powered by blists - more mailing lists