racing ndo_open()/phylink*connect() with phy_probe()

[Andrew Lunn]

> > It seems unlikely, but one possibility is:
> > 
> > static int stmmac_xgmac2_mdio_read_c22(struct mii_bus *bus, int phyaddr,
> >                                        int phyreg)
> > {
> >         struct net_device *ndev = bus->priv;
> >         struct stmmac_priv *priv;
> >         u32 addr;
> > 
> >         priv = netdev_priv(ndev);
> > 
> >         /* Until ver 2.20 XGMAC does not support C22 addr >= 4 */
> >         if (priv->synopsys_id < DWXGMAC_CORE_2_20 &&
> >             phyaddr > MII_XGMAC_MAX_C22ADDR)
> >                 return -ENODEV;
> > 
> > Maybe if the interface is down, priv->synopsys_id has not been set
> > yet? Your devices are at address 8 and 10, so if priv->synopsys_id
> > where 0, this would give you the ENODEV.
> 
> Yes, I did look at that, but didn't read the DT snippet to realise
> that the addresses would be trapped by that. So, looking at where
> priv->synopsys_id is set... is in stmmac_hwif_init(), which is
> called from stmmac_hw_init(), which in turn is called from
> stmmac_dvr_probe(). This is the only path that leads here.
> 
> This all happens before the MDIO bus is registered, so the value of
> priv->synopsys_id should be set by the time the MDIO bus is registered.
> 
> So I'm unconvinced...

Me too. I just wanted to give an example of why it is important to
track down the source of the ENODEV.

      Andrew