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

[Kory Maincent <kory.maincent@bootlin.com>]

On Thu, 9 Apr 2026 21:54:33 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Thu, Apr 09, 2026 at 05:08:33PM +0100, Russell King (Oracle) wrote:
> > On Thu, Apr 09, 2026 at 05:34:56PM +0200, Andrew Lunn wrote:  
> > > I still think we should be deferring probe until we have all the parts
> > > available. The question is, how do we actually do that?  
> > 
> > Indeed...
> >   
> > > We could insist that MACs being used with PSE need to call
> > > phylink_connect() in probe, so we can return EPROBE_DEFER. We might
> > > actually need a new API method, phylink_connect_probe(). That can call
> > > down into phylib, maybe again new API methods, which will not bind
> > > genphy, but return EPROBE_DEFER.  
> 
> I did not say i would be easy...
>  
> > How would MACs know whether they should call phylink_connect_probe()
> > or phylink_connect_phy() ?  
> 
> It would not. Anybody with a board using PSE would need to modify the
> MAC driver to use phylink_connect_probe(), if they have a slow to load
> PSE device.
> 
> > What do we do about MAC drivers that are a single driver and device,
> > but are made up of several network devices (like Marvell PP2) ?  
> 
> It would need more care, but it should work. You might end up removing
> a perfectly good device because the other one is missing its PHY,
> which is not ideal, but hopefully you get there in the end.
> 
> > We also have network drivers that provide a MDIO bus for a different
> > network device, which makes connecting the PHY harder in the probe
> > path.  
> 
> Yes, we would see such setup doing more deferred probing, but again,
> they should get there in the end. The most common systems doing this
> are using the FEC. Are there any board using the FEC and problematic
> PSE?

Not that I know of but it is only the beginning of PSE support in Linux.

> > Lastly, what do we do where a PHY driver hasn't been configured or
> > doesn't exist for the PHY?  
> 
> I was wondering if we can get from the driver core some idea where we
> are in the deferred probing window. If we are 2/3 of the way through
> the window, fall back to genphy?

How could we decide when to fall back to genphy and when to continue the
defer situation?

> I'm not saying we should change all MAC drivers, or recommend new MAC
> drivers connect to the PHY in probe. I just want to offer the option
> if you have a problematic PSE or PHY, change the MAC driver.
> 
> What we have also said in the past, it is the bootloaders problem to
> download firmware into the PHY, or PSE, so that it is ready to go by
> the time Linux boots. That would also be the simpler solution here.

My thought of using MDI was to separate the hardware port from the PHY device,
as in hardware, the PSE is directly wired to the MDI we should have the binding
similar.
I was thinking of adding a new helper to register the MDIs for the MACs.
In the MAC/SWITCH binding we could have a list of MDIs similarly to that: 
https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/net/ethernet-phy.yaml#L332

We could have the SFP and PSE phandle directly in that node.
For example prestera driver is already doing something similar for SFP:
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/net/ethernet/marvell/prestera/prestera_main.c#L370

I wanted to convert this helper into a generic one. Then every MAC/Switch
driver could just simply call the new helper to register their MDIs. I am
surely missing lots of things as I am not as net expert as you, but what do you
think of that?

We would have one path into phylink and one trough the new helper when there is
no PHY devices registered.

Maxime what do you think as you are actively working on MDIs?

Still, this does not reply the initial question, should we keep EPROBE_DEFER
in phylink if the PSE is not found or should we have have a way to probe the
PHY and solve the PSE phandle later?

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