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

[Rob Herring <robh@kernel.org>]

On Tue, Sep 01, 2026 at 09:33:33AM +0200, Christophe ROULLIER wrote:
> 
> Le 12/08/2026 à 21:58, Rob Herring a écrit :
> > On Wed, Aug 12, 2026 at 11:11:18AM +0200, Christophe Roullier wrote:
> > > 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 <christophe.roullier@foss.st.com>
> > > ---
> > >   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