A PHY whose own driver is a module on a filesystem that is not mounted when the MAC probes gets the generic driver first. phy_probe() replaces phydev->irq with PHY_POLL because that driver has no interrupt support, nothing puts it back, and the PHY polls for the rest of the uptime once its real driver takes over. Take the number back in phy_detach(), from mdiobus->irq[], which is where phy_device_create() seeded phydev->irq from and where the bus that described the interrupt still holds it. Do it before device_release_driver() rather than after. That call returns with the mdio device bindable and the device lock dropped, so from then on a phy_probe() on another CPU is the other writer of this field. Ahead of it the generic driver is still bound, and a driver registering meanwhile is turned away with -EBUSY before it can reach phy_probe(). Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin --- Notes: Found and measured on an MT7981B board with an MT7531 switch and an Airoha EN8811H behind lan4, whose interrupt the devicetree describes and whose driver is a module. The one condition arranged for the run is that the PHY driver module loads after the root filesystem rather than from the early boot list this distribution normally puts it in. The distribution's own late-PHY handling was also removed, that being the one patch which could have changed the outcome; upstream has nothing like it. The kernel is still a distribution one and its remaining patches to phylink and phy_device do run on these paths - none of them writes phydev->irq. DSA then sets the port up at 1.87 s, the generic driver is bound by hand, phy_probe() replaces the interrupt with PHY_POLL, and phylink rejects 2500base-x against it: lan4 (uninitialized): validation of 2500base-x ... failed: -EINVAL lan4 (uninitialized): failed to connect to PHY: -EINVAL The real driver arrives between 13.4 and 13.6 s depending on the boot, and binds. phydev->irq then reads -1 without this patch and 15 with it, 15 being what the devicetree gave that PHY. The three switch ports alongside read 79, 80 and 81 in both runs, so the reading distinguishes rather than printing one answer. The field has no sysfs attribute of its own, so it was read with a debug-only module parameter that walks the MDIO bus and prints it. drivers/net/phy/phy_device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 94b2e85e00a3..8e6b399f95d6 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1959,6 +1959,9 @@ void phy_detach(struct phy_device *phydev) if (phydev->mdio.dev.driver) module_put(phydev->mdio.dev.driver->owner); + /* The release below can hand this field to a probe on another CPU. */ + phydev->irq = phydev->mdio.bus->irq[phydev->mdio.addr]; + /* If the device had no specific driver before (i.e. - it * was using the generic driver), we unbind the device * from the generic driver so that there's a chance a -- 2.53.0