Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Mon, Apr 06, 2026 at 02:22:16PM +0200, Andrew Lunn wrote:
> > The core question, do we need PSE for PHY functionality?
> 
> I don't think the PHY should require PSE in order to send/receive
> frames. If the PSE is not supplying power, the link peer is probably
> off, but that is not so different from the cable being unplugged.
> 
> > We can make a step back and re-evaluate - what functionality and what
> > order is actually required to find potentially better implementation.
> > 
> > We have a lot of current flowing over wires, budget and port
> > prioritization issues, things which may damage HW if done not correctly.
> > With other word, if we do not have properly operational environment
> > providing system specific policies, it is better to run safe
> > configuration - all ports/regulators are off.
> > 
> > This means:
> > - PSE controller driver should be registered as early as possible,
> >   without caring about existence of PHYs, ports or network interfaces.
> >   And configure ports in to default safe operation - off. Accept we
> >   have some controller/firmware which would care about safety.
> 
> Don't most PSE have I2C or SPI interfaces? So they have a different
> life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
> within a PHY, on an MDIO bus, will have a closely linked life
> cycle. But do such devices exist?

i'm not aware of any.

> As soon as the PSE probes with all the resources it needs, and can
> impose a safe default setting. And that can be independent of PHY and
> netdev. I _think_ we only need the netdev for configuration, since
> ethtool addresses netdev's.  There would only be issues with user
> space listening to udev creation events, it knows the PSE exists, but
> it has no way to access it until the netdev is created.

Ack. netdev is for configuration as virtual representation of PSE PI. And it
is easier to assign corresponding interface for the LLDP.
We do not really care about the PHY; it just happens to represent the
port at the farthest end described in the Device Tree.

> > - as soon as we have all needed components, we can start provide
> >   controllable interfaces to serve external consumers.
> 
> Yep.
> 
> > If we decouple PSE and PHY registration (and we probably will need to do
> > it some day), we would need to have own implementation of deferred
> > probing in the PSE core.  Event driven or by polling - which sounds not
> > like very good idea. Pick your poison...
> 
> I don't see why. Maybe i'm missing something. We have two cases:
> 
> 1) PSE probes first. When the PHY looks up the PSE, it exists, and it
> is passed a handle to the PSE.
> 
> 2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
> will try again later.
> 
> I don't think there is any chicken/egg problems.

Ack, i guess it is optimization problem.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |