[PATCH net-next 1/4] dt-bindings: net: document st,phy-wol property

[Russell King (Oracle)]

On Tue, Jul 22, 2025 at 10:59:51PM +0200, Andrew Lunn wrote:
> >         if (!priv->plat->pmt) {
> 
> Let me start with maybe a dumb question. What does pmt mean? Why would
> it be true?

->pmt being true means the MAC supports remote wakeup (in other words,
magic packet or unicast), and the glue driver has not set the
STMMAC_FLAG_USE_PHY_WOL flag to force the use of PHY WoL.

->pmt being false means that the MAC doesn't support remote wakeup
(in other words, has no ability to wake the system itself) _or_ the
platform wishes to force the use of PHY WoL when the MAC does support
remote wakeup.

> 
> >                 struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> > 
> >                 phylink_ethtool_get_wol(priv->phylink, &wol);
> >                 device_set_wakeup_capable(priv->device, !!wol.supported);
> >                 device_set_wakeup_enable(priv->device, !!wol.wolopts);
> 
> Without knowing what pmt means, this is pure speculation....  Maybe it
> means the WoL output from the PHY is connected to a pin of the stmmac.
> It thus needs stmmac to perform the actual wakeup of the system, as a
> proxy for the PHY?

stmmac itself doesn't have an input for PHY interrupts, so a PHY
which signals WoL via its interrupt pin (e.g. AR8035) wouldn't go
through stmmac.


I mentioned above the STMMAC_FLAG_USE_PHY_WOL flag. To see why this
flag is needed, on the Jetson Xavier NX platform, a RTL8211 PHY is used
with stmmac - I think it's RTL8211F (without powering it back up, I
can't check.) This PHY supports WoL, but signals wake-up through a
dedicated PMEB pin. If a platform decides not to wire the PMEB pin, WoL
on the PHY is unusable.

rtl8211f_get_wol() does not take account of whether the PMEB pin is
wired or not. Thus, stmmac can't just forward the get_wol() and
set_wol() ops to the PHY driver and let it decide, as suggested
earlier. As stmmac gets used with multiple PHYs, (and hey, we can't
tell what they are, because DT doesn't list what the PHY actually is!)
we can't know how many other PHY drivers also have this problem.

So, the idea put forward that ethernet drivers should forward get_wol()
and set_wol() to the PHY driver and only do WoL at the MAC if the PHY
doesn't support it is, I'm afraid, now fundamentally flawed.

We can't retrofit such detection into PHY drivers - if we do so, we'll
break WoL on lots of boards (we'd need to e.g. describe PMEB in DT for
RTL8211F PHYs. While we can add it, if a newer kernel that expects
PMEB to be described to allow WoL is run with an older DT, then that
will be a regression.) Thus, I don't see how we could retrofit PHY
WoL support detection to MAC drivers.

So, while it is undesirable to have a flag in DT to say "we can use
PHY WoL on this platform" and we can whinge that it isn't "describing
hardware", DT _hasn't_ been describing the hardware, and trying to fix
DT to properly describe the hardware now is going to cause _lots_ of
breakage.

I can't see a way forward on this unless someone is willing to relax
over what seem to be hard requirements (e.g. no we don't want a flag
in DT to say use PHY WoL.) We have collectively boxed ourselves into
a corner on this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!