[PATCH net v8 4/4] net: phy: restore the interrupt when the generic bind cycle fails

From: Aleksei Sviridkin

Date: Thu Sep 17 2026 - 22:00:32 EST


phy_attach_direct() binds the generic driver by hand, and the probe it
calls is phy_probe(), which replaces phydev->irq with PHY_POLL before
either of the points it can fail at. That failure unwinds on a label of
its own, which does not go through phy_detach(), so the substitution
outlives a bind cycle that never completed and a later attach finds a
PHY that can only be polled.

Take the number back on that label as well, before it clears d->driver.
That store is what reopens the device to the driver core: until it runs,
a driver registering on another CPU is turned away with -EBUSY and
phy_probe() cannot be the second writer of this field.

Fixes: 6d9f66ac7fec ("net: phy: Fix PHY module checks and NULL deref in phy_attach_direct()")
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@xxxxxx>
---

Notes:
Both points the hand-bind can fail at are reachable. phy_probe() reaches
genphy_read_abilities() through genphy_driver's .get_features, and that
returns the error from phy_read(phydev, MII_BMSR); device_bind_driver()
returns whatever driver_sysfs_add() got from sysfs_create_link().

A failed genphy bind leaves the device with no driver bound at all, so the
next driver to arrive binds directly and never goes through phy_detach().
That is why patch 3 cannot cover this path, and why the Fixes: tag here is
6d9f66ac7fec rather than the one patch 3 carries. That commit did not
introduce the lost number - the substitution is far older - it created this
second exit from the bind cycle, splitting the failure off the label that
calls phy_detach(). Before it, patch 3 alone would have covered this, so
that is where the backport range for this one starts.

Exercised on the board described in patch 3, with a debug-only module
parameter that fails the hand-bound generic probe once for one MDIO
address. The connect then ends in -EIO rather than the -EINVAL of the
validation path, so the unwind takes the label this patch touches.
phydev->irq afterwards reads -1 with patch 3 alone and 15 with this one.

One difference between the injector and a real failure, since it does not
affect what was measured but should not be implied away: a genuine error
inside phy_probe() leaves through its out: label, which re-asserts the PHY
reset before returning, while the injector returns earlier than that.
Neither path touches phydev->irq.

drivers/net/phy/phy_device.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 8e6b399f95d6..69d8911ea7f6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1896,6 +1896,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,

error_module_put:
module_put(d->driver->owner);
+ /* Before the NULL below, which lets another probe reach this field. */
+ phydev->irq = bus->irq[phydev->mdio.addr];
phydev->is_genphy_driven = 0;
d->driver = NULL;
error_put_device:
--
2.53.0