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

[Florian Fainelli <florian.fainelli@broadcom.com>]

On 7/23/25 07:23, Andrew Lunn wrote:
>> 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.
> 
> WoL is a mess. I wounder on how many boards it actually works
> correctly? How often is it tested?
 > > I actually think this is similar to pause and EEE. Those were also a
> mess, and mostly wrongly implemented. The solution to that was to take
> as much as possible out of the driver and put it into the core,
> phylink.
> 
> We probably want a similar solution. The MAC driver indicates its WoL
> capabilities to phylink. The PHY driver indicates its capabilities to
> phylink. phylink implements all the business logic, and just tells the
> PHY what it should enable, and stay awake. phylink tells the MAC what
> is should enable, and that it should stay awake.

We would need both a phylib and a phylink set of helpers because not all 
of the drivers need to be converted to phylink.

> 
> Is this going to happen? Given Russell limited availability, i guess
> not. It needs somebody else to step up and take this on. Are we going
> to break working systems? Probably. But given how broken this is
> overall, how much should we actually care? We can just fix up systems
> as they are reported broken.

Please just refrain from making such statements, it really just does not 
help, and if you have no direct hands on experience with Wake-on-LAN, it 
becomes purely gratuitous. I agree that there is a lack of adequate 
consistency and guidelines for developers to implement Wake-on-LAN 
properly, but I don't agree with the message and the way it is 
delivered. It's just completely antagonistic to people like me and my 
colleagues who have spent a great deal of time implementing Wake-on-LAN 
for actively used systems, and I am talking hundred of millions of STBs 
deployed each of them doing hundreds of system suspend/resume involving 
Wake-on-LAN per day.

> 
> I also think WoL, pause and EEE is a space we should have more tests
> for. To fully test WoL and pause you need a link partner, but i
> suspect you can do some basic API tests without one. WoL you
> definitely need a link partner. So this makes testing a bit more
> difficult. But that should not stop the community from writing such
> tests and making them available for developers to use.

The tests are in premise very simple, but you need a link partner and 
you need to be ideally on the same physical network and you need to have 
a system that supports system wide wake-up, or if nothing else s2idle. 
Then you need a secondary wake-up source like a RTC or GPIO in order to 
ensure that there is an upper bound on when you timeout for not 
receiving a proper wake-on-LAN trigger.

It's not clear to me what needs to be contributed to the community, but 
essentially the pseudo code is something like:

- wait for DUT to boot
for each support Wake-on-LAN mode:
	- configure wake-on-LAN on DUT
	- snapshot /sys/*/wakeup_count for the MAC/PHY device
	- enter standby with e.g.: rtcwake -s <TIMEOUT> -m mem
	- send Wake-on-LAN trigger from external device
	- ensure DUT woke-up before <TIMEOUT> and check that /sys/*wakeup_count 
is +1 compared to the previous snapshot
-- 
Florian