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

[Kory Maincent]

On Thu, 9 Apr 2026 14:30:53 +0200
Andrew Lunn <andrew@xxxxxxx> wrote:

> On Wed, Apr 08, 2026 at 11:07:11PM +0200, Carlo Szelinsky wrote:
> > So I went ahead and tested the phy_probe() approach on my setup (RTL930x
> > DSA switch with an I2C Hasivo HS104 PSE controller as module).
> > 
> > PoE itself works fine, but phydev->psec never gets set - ethtool just
> > says "No PSE is attached" on all ports.
> > 
> > Took me a while to figure out what's going on. The problem is how DSA
> > handles PHYs: when phy_probe() returns -EPROBE_DEFER because the PSE
> > controller hasn't probed yet, the PHY device is registered but sits
> > there unprobed. Then the DSA switch comes along, sets up its ports, and
> > phy_attach_direct() force-binds the generic PHY driver with
> > device_bind_driver(). Now the device already has a driver, so when the
> > deferred probe retry kicks in it just skips it. phy_probe() never runs
> > again and psec stays NULL.
> > 
> > What I'm seeing timing-wise:
> >   - MDIO scan registers PHYs, phy_probe() defers (no PSE yet)
> >   - DSA probes, phy_attach_direct() binds genphy
> >   - t=17s: HS104 finally probes
> >   - deferred retry: nope, driver already bound
> >   - t=35s: regulator_late_cleanup (caught by admin_state_synced)
> > 
> > Not sure what the best path forward is here. Should we look at fixing
> > phy_attach_direct() to handle this case, or go back to the non-fatal
> > EPROBE_DEFER approach from v2 for now?  
> 
> I thought about this some more. Looking at the phydev->drv might solve
> it for DSA switches, but it is not a general solution for when the PSE
> is used with a normal MAC, and the phylink_connect() happens in
> open().
>
> Now, the HS104 appears to be a quad device, intended for switches. So
> maybe solving the issue only for DSA is O.K?
> 
> Otherwise, maybe we need the ability to associate the PSE controller
> to the MAC? At a quick look, PSE and PHY are not tightly bound
> together. So we could make the MAC driver call something similar to
> of_pse_control_get() in its probe function, where it can return
> EPRODE_DEFFER. net/ethtool/pse-pd.c would need some changes as well.

I don't think we should associate it to the MAC. In a hardware point of view the
PSE Power Interfaces are wired the MDIs. It was associated historically to the
PHY, because, at that time there was no representation of the MDI. Now thanks
to Maxime there is, so in the future we should associate the PSE control to the
MDI only. We will already have to keep the PHY association compatibility to not
break binding API but please do not add another layer of association that will
increase more compatibility burden for the future.

As I proposed in another thread, if the PHY can't find the PSE PI, we could
save the phandle of the PSE PI somewhere in the PHY structure. Then at PSE
register time, look for each PHY and try to resolve every unresolved phandle.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com