Message-ID: <b6e99d7b-2cb7-c892-3bd2-fa545ae9056b@gmail.com>
Date:   Sun, 27 Jun 2021 20:29:20 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        Vladimir Oltean <olteanv@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Michal Kubecek <mkubecek@...e.cz>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: 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:
>>> - 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?
> 
> 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

Powered by blists - more mailing lists