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

Andrew Lunn
2026-04-06T12:22:34Z

> 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?

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.

> - 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.

Andrew