Re: [PATCH v1 1/2] driver core: fw_devlink: Add support for FWNODE_FLAG_BROKEN_PARENT
From: Saravana Kannan <hidden>
Date: 2021-08-26 23:45:40
Also in:
linux-acpi, lkml
On Thu, Aug 26, 2021 at 1:53 PM Andrew Lunn [off-list ref] wrote:
quoted hunk ↗ jump to hunk
quoted
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 [off-list ref] 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@gmail.com/ (local) -Saravana