Message-ID: <0aae6527-6b1d-31e4-1b9d-52f2174634b3@gmail.com>
Date:   Mon, 28 Jun 2021 21:53:52 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        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>
Subject: Re: PHY vs. MAC ethtool Wake-on-LAN selection

On 27.06.2021 05:53, Florian Fainelli wrote:
> 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?
> 
Hi Florian,

your question regarding r8169 is a little bit hard to answer because there's no public chip documentation.
What I can say is how the driver behaves. If WOL is enabled then the MAC is kept active (receiver enabled,
no PLL power-down). This indicates that for certain WOL types MAC support is needed, I didn't test yet
whether e.g. WAKE_PHY works with the MAC disabled.

> Thanks!

Heiner

Powered by blists - more mailing lists