Message-ID: <20250917-wol-smsc-phy-v2-0-105f5eb89b7f@foss.st.com>
Date: Wed, 17 Sep 2025 17:36:35 +0200
From: Gatien Chevallier <gatien.chevallier@...s.st.com>
To: Andrew Lunn <andrew+netdev@...n.ch>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "Alexandre Torgue" <alexandre.torgue@...s.st.com>,
        Christophe Roullier
	<christophe.roullier@...s.st.com>,
        Andrew Lunn <andrew@...n.ch>,
        "Heiner
 Kallweit" <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "Simon Horman" <horms@...nel.org>,
        Tristram Ha <Tristram.Ha@...rochip.com>,
        "Florian Fainelli" <florian.fainelli@...adcom.com>
CC: <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        Gatien Chevallier <gatien.chevallier@...s.st.com>
Subject: [PATCH net-next v2 0/4] net: add WoL from PHY support for
 stm32mp135f-dk

A previous patchset in drivers/net/phy/smsc.c introduced the WoL
from PHY capability of some PHYs. The Microchip LAN8742 PHY is
present on the stm32mp135f-dk board and posesses this capability.

Therefore, add the possibility to specify in the device tree that,
for a MAC instance, we want to use the WoL from PHY capability
instead of the MAC one.

However, when testing multiple power sequences with magic packets,
the first one succeeded but the following ones failed. This was
caused by uncleared flags in a PHY register. Therefore, I added
a patch to add suspend()/resume() callbacks that handle these.
These callbacks are only implemented for the Microchip LAN8742 as I
have no way of testing it for other WoL capable PHYs.

Note: This patchset does not solve the issue regarding the PHY pin
alternate fuctions (nPME/nINT). The driver still statically configures
the LED2/nINT/nPME in nPME mode. The interrupt management discussed in
V1 still needs rework, and probably at framework level.

The current state after this patchset is:
- Successive system wakeup with WoL event now possible
- WoL event received while the system is up do not prevent system wakeup
  from a WoL event. I took inspiration from the broadcom driver
  regarding this issue

Question: Given that the PHYs have pins with alternate functions that
are difficult to handle (some drivers like smsc.c are configuring them
statically), should we consider working on a pinctrl-like solution for
them?

Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
---
Changes in v2:
- Rework commit message of the bindings patch
- Handle WoL flags in Microchip driver suspend() callback and always
  call the suspend callback.
- Link to v1: https://lore.kernel.org/r/20250721-wol-smsc-phy-v1-0-89d262812dba@foss.st.com

---
Gatien Chevallier (4):
      dt-bindings: net: document st,phy-wol property
      net: stmmac: stm32: add WoL from PHY support
      net: phy: smsc: fix and improve WoL support
      arm: dts: st: activate ETH1 WoL from PHY on stm32mp135f-dk

 .../devicetree/bindings/net/stm32-dwmac.yaml       |  6 ++
 arch/arm/boot/dts/st/stm32mp135f-dk.dts            |  1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  |  5 ++
 drivers/net/phy/smsc.c                             | 66 ++++++++++++++++++++--
 include/linux/smscphy.h                            |  2 +
 5 files changed, 75 insertions(+), 5 deletions(-)
---
base-commit: 5e87fdc37f8dc619549d49ba5c951b369ce7c136
change-id: 20250721-wol-smsc-phy-ff3b40848852

Best regards,
-- 
Gatien Chevallier <gatien.chevallier@...s.st.com>

Powered by blists - more mailing lists