Message ID | 612b81d5-c4c1-5e20-a667-893eeeef0bf5@gmail.com |
---|---|
State | Accepted |
Delegated to: | David Miller |
Headers | show |
Series | [net-next,v2] net: phy: probe PHY drivers synchronously | expand |
On 3/26/2020 5:00 PM, Heiner Kallweit wrote: > If we have scenarios like > > mdiobus_register() > -> loads PHY driver module(s) > -> registers PHY driver(s) > -> may schedule async probe > phydev = mdiobus_get_phy() > <phydev action involving PHY driver> > > or > > phydev = phy_device_create() > -> loads PHY driver module > -> registers PHY driver > -> may schedule async probe > <phydev action involving PHY driver> > > then we expect the PHY driver to be bound to the phydev when triggering > the action. This may not be the case in case of asynchronous probing. > Therefore ensure that PHY drivers are probed synchronously. > > Default still is sync probing, except async probing is explicitly > requested. I saw some comments that the intention is to promote > async probing for more parallelism in boot process and want to be > prepared for the case that the default is changed to async probing. > > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
On Fri, Mar 27, 2020 at 01:00:22AM +0100, Heiner Kallweit wrote: > If we have scenarios like > > mdiobus_register() > -> loads PHY driver module(s) > -> registers PHY driver(s) > -> may schedule async probe > phydev = mdiobus_get_phy() > <phydev action involving PHY driver> > > or > > phydev = phy_device_create() > -> loads PHY driver module > -> registers PHY driver > -> may schedule async probe > <phydev action involving PHY driver> > > then we expect the PHY driver to be bound to the phydev when triggering > the action. This may not be the case in case of asynchronous probing. > Therefore ensure that PHY drivers are probed synchronously. > > Default still is sync probing, except async probing is explicitly > requested. I saw some comments that the intention is to promote > async probing for more parallelism in boot process and want to be > prepared for the case that the default is changed to async probing. > > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Andrew
From: Heiner Kallweit <hkallweit1@gmail.com> Date: Fri, 27 Mar 2020 01:00:22 +0100 > If we have scenarios like > > mdiobus_register() > -> loads PHY driver module(s) > -> registers PHY driver(s) > -> may schedule async probe > phydev = mdiobus_get_phy() > <phydev action involving PHY driver> > > or > > phydev = phy_device_create() > -> loads PHY driver module > -> registers PHY driver > -> may schedule async probe > <phydev action involving PHY driver> > > then we expect the PHY driver to be bound to the phydev when triggering > the action. This may not be the case in case of asynchronous probing. > Therefore ensure that PHY drivers are probed synchronously. > > Default still is sync probing, except async probing is explicitly > requested. I saw some comments that the intention is to promote > async probing for more parallelism in boot process and want to be > prepared for the case that the default is changed to async probing. > > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Applied, thanks Heiner.
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index d6024b678..ac2784192 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -2575,6 +2575,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) {
If we have scenarios like mdiobus_register() -> loads PHY driver module(s) -> registers PHY driver(s) -> may schedule async probe phydev = mdiobus_get_phy() <phydev action involving PHY driver> or phydev = phy_device_create() -> loads PHY driver module -> registers PHY driver -> may schedule async probe <phydev action involving PHY driver> then we expect the PHY driver to be bound to the phydev when triggering the action. This may not be the case in case of asynchronous probing. Therefore ensure that PHY drivers are probed synchronously. Default still is sync probing, except async probing is explicitly requested. I saw some comments that the intention is to promote async probing for more parallelism in boot process and want to be prepared for the case that the default is changed to async probing. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- drivers/net/phy/phy_device.c | 1 + 1 file changed, 1 insertion(+)