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

[Kory Maincent]

On Mon, 6 Apr 2026 10:42:31 +0200
Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:

> Hi,
> 
> On Fri, Apr 03, 2026 at 03:38:49PM +0200, Kory Maincent wrote:
> > On Fri,  3 Apr 2026 15:31:11 +0200
> > Carlo Szelinsky <github@xxxxxxxxxxxx> wrote:
> >   
> > > Hi Andrew,
> > > 
> > > Thx for helping me! 
> > > I thought of keeping the eager path so we still catch broken DT bindings
> > > early at boot instead of silently failing later on first ethtool access.
> > > But you're right, dropping it would simplify things quite a bit. Do you
> > > think that trade-off is worth it? I will follow your lead.   
> > 
> > On my side I thinks that's a good idea, and I don't see any issue with that
> > for now. Oleksij you introduced it here in the first place, is it ok for
> > you?  
> 
> If I see it correctly - this patch kills all notifications originated
> from the PSE core to the users space, until some one calls get/set path
> from user space. Means, kernel update may break UAPI behavior of
> existing devices.

Indeed you are right, I have missed this point.

> On other hand, I agree that PSE is not a strickt requirement for PHY
> functionality in most cases. At the early stage, as initial PSE support
> was introduced, PHYs was kind of representation of the port and related
> ethernet interface (needed for LLDP). Are there better methods to solve
> it now?

Now that Maxime has merged the phy port representation (mdi) it could be binding
to it. But we should not break the current uAPI of having it bind directly
to the PHY. Thing is, the issue will be still present as PHY ports are only
created and initialized at probe time.

We should be able to get the PSE control either at PSE register time or at PHY
(or PHY port) probe time.

I just see there is more discussion about it in the thread.

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