[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <222fed4c-1613-40ec-b0a2-35b181fac795@lunn.ch>
Date: Fri, 14 Jun 2024 16:47:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Paul Geurts <paul.geurts@...drive-technologies.com>
Cc: wei.fang@....com, shenwei.wang@....com, xiaoning.wang@....com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, imx@...ts.linux.dev, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fec_main: Register net device before initializing the
MDIO bus
On Fri, Jun 14, 2024 at 10:40:50AM +0200, Paul Geurts wrote:
> > On Thu, Jun 13, 2024 at 04:41:11PM +0200, Paul Geurts wrote:
> > > Registration of the FEC MDIO bus triggers a probe of all devices
> > > connected to that bus. DSA based Ethernet switch devices connect to the
> > > uplink Ethernet port during probe. When a DSA based, MDIO controlled
> > > Ethernet switch is connected to FEC, it cannot connect the uplink port,
> > > as the FEC MDIO port is registered before the net device is being
> > > registered. This causes an unnecessary defer of the Ethernet switch
> > > driver probe.
> > >
> > > Register the net device before initializing and registering the MDIO
> > > bus.
> >
> > The problem with this is, as soon as you call register_netdev(), the
> > device is alive and sending packets. It can be sending packets even
> > before register_netdev() returns, e.g. in the case of NFS root. So
> > fec_enet_open() gets called, and tried to find its PHY. But the MDIO
> > bus is not registered yet....
>
> Valid argument there. I was trying to make the initialization more efficient,
> but you are correct.
Any changes to make this more efficient probably needs to be generic,
and not in a specific Ethernet driver. One idea might be, when parsing
the DT node for the MDIO bus, look to see if the device on the bus has
a compatible which indicates it is not a PHY. If so, try to make the
driver core put the device straight into deferred state, without even
trying the first probe.
Also, look at driver core devlink stuff. It tries to keep track of
resource dependencies, and only probe devices when their resources are
available. It does not seem to understand DSA too well, and it might
be made better. But this is complex, we have dependency loops in
network drivers, which causes devlink issues.
Andrew
Powered by blists - more mailing lists