Thread (9 messages) 9 messages, 2 authors, 2026-09-01

Re: [net-next,PATCH v2 1/5] dt-bindings: net: add phy-supply property for stm32

flat view

From: Rob Herring <robh@kernel.org>
Date: 2026-09-01 14:01:57
Also in: linux-arm-kernel, linux-devicetree, lkml

On Tue, Sep 01, 2026 at 09:33:33AM +0200, Christophe ROULLIER wrote:
Le 12/08/2026 à 21:58, Rob Herring a écrit :
quoted
On Wed, Aug 12, 2026 at 11:11:18AM +0200, Christophe Roullier wrote:
quoted
Phandle to a regulator that provides power to the PHY. This
regulator will be managed during the PHY power on/off sequence.

Signed-off-by: Christophe Roullier <redacted>
---
  Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 3 +++
  1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index 987254900d0da..0c7eb1ccadd47 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -99,6 +99,9 @@ properties:
        encompases the glue register, the offset of the control register and
        the mask to set bitfield in control register
+  phy-supply:
+    description: PHY regulator
Which phy? There can be multiple for ethernet. In any case, doesn't
really matter because either is wrong. The supply(ies) for a device go
in that device's DT node. This node is not a PHY.

Rob
Hi Rob,

Ok I will update my description with :   "Regulator that powers the Ethernet
PHY."

To manage this regulator on Ethernet glue, I based my work on the examples
of :

  - allwinner,sun4i,

  - allwinner,sun7i

  - allwinner,sun8i

  - fsl,fec

  - rockchip-dwmac

  - rockchip,emac
There are plenty of examples of how not to model things in the tree.
For me it is normal that PHY Ethernet regulator is managed by MAC glue
because it is mandatory to power ON Ethernet PHY chip BEFORE MDIO scan.
What happens when you have a PHY with a supply, clock, and reset that 
all need handling and those all need to be handled in a specific order 
and timing? And then you have 10 different boards with different PHYs 
and different power on requirements? You are not going to handle that in 
the MAC driver. We've fallen into the trap of "I just need this one 
property" many times. It doesn't scale.

The MDIO subsystem has provisions for handling power on of devices 
before discovery. I know it will generically enable a clock. Maybe a 
single regulator is handled too, I don't recall. If the PHY gets more 
complicated, then you need a specific PHY driver to handle it.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help