On Thu, Aug 26, 2021 at 1:53 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > > The DT node in [2] is probed by realtek_smi_probe() [3]. The call flow is: > > realtek_smi_probe() > > -> dsa_register_switch() > > -> dsa_switch_probe() > > -> dsa_tree_setup() > > -> dsa_tree_setup_switches() > > -> dsa_switch_setup() > > -> ds->ops->setup(ds) > > -> rtl8366rb_setup() > > -> realtek_smi_setup_mdio() > > -> of_mdiobus_register() > > This scans the MDIO bus/DT and device_add()s the PHYs > > -> dsa_port_setup() > > -> dsa_port_link_register_of() > > -> dsa_port_phylink_register() > > -> phylink_of_phy_connect() > > -> phylink_fwnode_phy_connect() > > -> phy_attach_direct() > > This checks if PHY device has already probed (by > > checking for dev->driver). If not, it forces the > > probe of the PHY using one of the generic PHY > > drivers. > > > > So within dsa_register_switch() the PHY device is added and then > > expected to have probed in the same thread/calling context. As stated > > earlier, this is not guaranteed by the driver core. > > Have you looked at: > > commit 16983507742cbcaa5592af530872a82e82fb9c51 > Author: Heiner Kallweit <hkallweit1@xxxxxxxxx> > Date: Fri Mar 27 01:00:22 2020 +0100 > > net: phy: probe PHY drivers synchronously > > See the full commit message, but the code change is: > > iff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c > index 3b8f6b0b47b5..d543df282365 100644 > --- a/drivers/net/phy/phy_device.c > +++ b/drivers/net/phy/phy_device.c > @@ -2577,6 +2577,7 @@ int phy_driver_register(struct phy_driver *new_driver, struct module *owner) > new_driver->mdiodrv.driver.probe = phy_probe; > new_driver->mdiodrv.driver.remove = phy_remove; > new_driver->mdiodrv.driver.owner = owner; > + new_driver->mdiodrv.driver.probe_type = PROBE_FORCE_SYNCHRONOUS; > > retval = driver_register(&new_driver->mdiodrv.driver); > if (retval) { > > How does this add to the overall picture? Doesn't add much to the discussion. In the example I gave, the driver already does synchronous probing. If the device can't probe successfully because a supplier isn't ready, it doesn't matter if it's a synchronous probe. The probe would still be deferred and we'll hit the same issue. Even in the situation the commit [5] describes, if parallelized probing is done and the PHY depended on something (say a clock), you'd still end up not probing the PHY even if the driver is present and the generic PHY would end up force probing it. [5] - https://lore.kernel.org/netdev/612b81d5-c4c1-5e20-a667-893eeeef0bf5@xxxxxxxxx/ -Saravana