From nobody Mon Sep 28 09:59:42 2026 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A2ED364E9A for ; Mon, 24 Aug 2026 02:40:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539247; cv=none; b=lRdrsd1XKosgn4xB2M3VbiafRbYzlL8fIp9cmmN+ueZOBk5kRCX8XEKnrE7yx9f7rI63OqLME/0Q8PUK3DMs50OVHNnqRuiwPbC1/u6lNY51bv4dFRB89hyEZTSp7VDL/lJN/WKQ/tqxLs3T1Yr6txR7An1lxq13WxvL4ETAK8s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539247; c=relaxed/simple; bh=+3Wg4hev+RdHrstqfxAhur7flQ+aLkM6Csxu2Qs/c+E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BMhv8iVqRwTtYhvHoKfm/QooYlZtl9WCwBFxJUpirpEmoZHT24Ha696BqYUvu0MdElD5nRNo3zXGXYXMvRR11mg/sZ2sHqAFo533UdgxUam7TX1VPHWZUkXUUbKOP3+dPR4CIYfd461BZz0qPxm2W4ZKkdDNa5ad9wrONjyNDik= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la; spf=pass smtp.mailfrom=lex.la; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b=hoaR3SL1; arc=none smtp.client-ip=209.85.218.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lex.la Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b="hoaR3SL1" Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-c15d3cd51b2so443297266b.3 for ; Sun, 23 Aug 2026 19:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787539240; x=1788144040; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=bcLtMagmgkZbYwvDV0YgYY3BoJUyu7By6WJbKfTcwDY=; b=hoaR3SL1Ww1/mQRiIW6LS81s/G9uB68JMqWDoUUbSe8mbkRa2SvHQl2Q0wmGzhQb45 qe6QNSoUeUjG26vBliBqpmownUa8g8bEcD/0IwkbQctugivA4cerBAGVDdkOKW2sNXPM z3ZDOf+rv4F8tIeJWKjFS5n/57SNe1zErVUrHP5caWMLRcRaAL14GFkyVCKHGcp6jp4s 4fkUXGRrFJrQbekt1QwC50zdZ29hT7gGRJGVgyDI/W0GmvxOXOqkWPY+i5Qt1IhoYc7R R1HLdDCpkWLS7s0uRSIeimnJsa91adebE8R/zLc3435J2M8zv1HIeHU8S9noY8b9Gyr2 Jbuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787539240; x=1788144040; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=bcLtMagmgkZbYwvDV0YgYY3BoJUyu7By6WJbKfTcwDY=; b=mmLMbl/P6sygYrd5JNGqfDzCMN+tYBKgVbFC220fZQbXgpAw2nDU20uVror7Rv5Nve LHOeb13812sWlS224TAufW3V931YXBRnxEaGKmA40nw/sH6CNg1AQnuAw1EI05JcFPzP E5KYQuk2yX+qp3IhMLR5+p6AEFFgQebg3gwDWDXX1F+heFeu/k00eHwplALb/Srgw0+q xGAAjYfPFaXPY9GdDYtdaxB49+BIQmXQuY1PJDPMpOYdteCnBdpPZOOYFWCwIBTWqgjm ScVnCq+KXkJdw1f1KRl0/cp6fme6w5f6o6LSGxfk4WIZO6vVqBDIC93hBY1Ie7fKJ1Ga AuzA== X-Forwarded-Encrypted: i=1; AHgh+RoamcTtvBVbc43Z9O4/78sgoiMys5ID+6TI1kJ3URT74DbChMb22gQ8ehkS/DzFiGQJh/Yb3NFg2IBCATU=@vger.kernel.org X-Gm-Message-State: AFuF++nWBWzzY/eY8opBtT51hm3STPuDO5eXrmvgIb7cD+PfnIygh7FF QY84T/ahvp/5kdqsTNzj8HCllJKld3raRuhWQn01coFqjPV69u/6E9b9x6vVj4HU5xU= X-Gm-Gg: AR+sD12AQGrroGAXBQugyrdyKumK9kK+9mscloIReI08JwPgtQUfiME1rLrbMwiz0BS +uf9LvR95CAp8Q9wiMrocNGmb83MlhCEjU0h/fevYHEIZgeJ1Mo8QrHeDHybGl8LqTtLw9qJdqQ AxauQQm+HPeA+fv8lZUEgYPhbUZBXnEm6qc2sh3zpVryiyNqQM9HtnHFgY3oMoSXoiF7YhSIeyH 67ciMuNAwXNXix9Y3UkNQXL/C0Sgfs+f9ck8vKfL61pPi492K8x+GagqQWdXejeKLrpxLAwpoQz 4was01nglbATVLH0WN1MIVKV7zD8OKXYj4FrgHUCGWFp7f4OLnVx/yyI2HRzIj0KuWduSXywiAf ZakraIj9pcIJdXdEAuUdpVSFTJpHs/2nuZKTOR0y78UOgiOoKsJlfWUlZtdd6/uhx2KIRFJ01GO HBF4+oNyqUB4L6xVueh267Kzh2/emmmrdDLFivsr0/eUMe8Duc1hCYYBb4 X-Received: by 2002:a17:907:a089:b0:c21:450d:cd88 with SMTP id a640c23a62f3a-c24924b8000mr1721172966b.6.1787539240649; Sun, 23 Aug 2026 19:40:40 -0700 (PDT) Received: from ownbook ([195.181.160.194]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24966f8f2asm1051909566b.36.2026.08.23.19.40.36 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 23 Aug 2026 19:40:40 -0700 (PDT) From: Aleksei Sviridkin To: Andrew Lunn , Heiner Kallweit , Russell King Cc: Aleksei Sviridkin , Vladimir Oltean , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next v2 1/2] net: phylink: unwind the PHY binding when bringup fails late Date: Mon, 24 Aug 2026 05:40:27 +0300 Message-ID: <20260824024029.41310-2-f@lex.la> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260824024029.41310-1-f@lex.la> References: <20260824024029.41310-1-f@lex.la> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" phylink_bringup_phy() records the PHY in pl->phydev before its last fallible step: on a MAC whose phylink ops implement LPI, phy_eee_rx_clock_stop() can fail with a real MDIO error. The callers unwind with phy_detach(), which knows nothing about pl->phydev, so a pointer to a PHY that is no longer attached outlives the failed connect. What that costs depends on how the caller got here. phylink_connect_phy() and the SFP path go through phylink_attach_phy(), which refuses to attach while pl->phydev is set and turns a transient MDIO error into a permanent -EBUSY. phylink_fwnode_phy_connect() has no such check, so a later connect overwrites the stale pointer and hides the problem. A disconnect does not: phylink_disconnect_phy() hands that pointer to phy_disconnect(), and the second phy_detach() on the same PHY drops references the first one already released. Clear the binding on the failure path. This is the same operation phylink_disconnect_phy() performs, so both now share a helper. The PHY-side fields are left to phy_detach(), which every caller already runs on this path. Fixes: 03abf2a7c654 ("net: phylink: add EEE management") Signed-off-by: Aleksei Sviridkin Reviewed-by: Andrew Lunn --- drivers/net/phy/phylink.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 5b8e956902fb..a55e4a64028f 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -2083,6 +2083,18 @@ static int phylink_validate_phy(struct phylink *pl, = struct phy_device *phy, return phylink_validate(pl, supported, state); } =20 +/* Disassociate @phy from @pl. Caller must hold pl->phydev_mutex. */ +static void phylink_clear_phydev(struct phylink *pl, struct phy_device *ph= y) +{ + mutex_lock(&phy->lock); + mutex_lock(&pl->state_mutex); + pl->phydev =3D NULL; + pl->phy_enable_tx_lpi =3D false; + pl->mac_tx_clk_stop =3D false; + mutex_unlock(&pl->state_mutex); + mutex_unlock(&phy->lock); +} + static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy, phy_interface_t interface) { @@ -2197,6 +2209,12 @@ static int phylink_bringup_phy(struct phylink *pl, s= truct phy_device *phy, if (ret =3D=3D 0 && phy_interrupt_is_valid(phy)) phy_request_interrupt(phy); =20 + if (ret) { + mutex_lock(&pl->phydev_mutex); + phylink_clear_phydev(pl, phy); + mutex_unlock(&pl->phydev_mutex); + } + return ret; } =20 @@ -2347,15 +2365,8 @@ void phylink_disconnect_phy(struct phylink *pl) =20 mutex_lock(&pl->phydev_mutex); phy =3D pl->phydev; - if (phy) { - mutex_lock(&phy->lock); - mutex_lock(&pl->state_mutex); - pl->phydev =3D NULL; - pl->phy_enable_tx_lpi =3D false; - pl->mac_tx_clk_stop =3D false; - mutex_unlock(&pl->state_mutex); - mutex_unlock(&phy->lock); - } + if (phy) + phylink_clear_phydev(pl, phy); mutex_unlock(&pl->phydev_mutex); =20 if (phy) { --=20 2.55.0 From nobody Mon Sep 28 09:59:42 2026 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36BCE373BFE for ; Mon, 24 Aug 2026 02:40:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539254; cv=none; b=TqtwJGXN075HdYDcWqyxm+fowmAoJ0zuX9T/8+7mymLezT2489pK3lTsuvV9jiEJ8zSTe1VuVxhj702o46OJGDB878bBLh/zhlacjD2d+glfAKYf18ArCPwuG8ObUU2spYuNTSCLCTx4F94LqGkeHapdGazRnDmSDfcXquBxsAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787539254; c=relaxed/simple; bh=ZmlYm3jxveF7tzH6WdQSj6F2s52ax7kuzJCcwgnCX3g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rTnCWLpgtyUm6t4BYwghoNi2gaT38MzPAl0X5dyVrdNJfe5EB5LnvfvGdgS+coc4tpLigiBNHE4an7BZwOucgG6A1cAgCkaogABilTEiqeWATWjT0uxjwsen+avgcXRZyfPD6NoALqNZ4OAtUXVrqu2q7ZUxFbw6aUUrTx1HyO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la; spf=pass smtp.mailfrom=lex.la; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b=BcyXNKth; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lex.la Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b="BcyXNKth" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c160420289bso423624366b.0 for ; Sun, 23 Aug 2026 19:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1787539245; x=1788144045; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=PFgu3uI6WNJeyj2BeGtQJ3I+sGN1TGHV3G/Qfqx6y0g=; b=BcyXNKthz3n7TkfS36c91/45Z5lAA1iCFnlb+dtTE4jgiXofJQIJ9ESu1vhuf5iVVD VjhSmwtVL1zolF0V/JWAHge91bILXRpL2CcMjD6g8lMfo2y/OM5o0JtveUzVzdftLmC/ 7FjhoIjYcM2632yuAv9tIWrIq/o0K0h1BXWeWTpyMhAj2HaYdL9au8g7scgnXGrLSFZ/ kQDb0hS+HEOx/RRAqYSglcEqXMuDv0qxQrojQkttdXkASF1dvVT/2eJWQ8+2QQhFlFSc aeq1+B+ISzttNgsy7B41anrFkgPxYnsDrDngClDCZLtYqobiiveb7ELIBaMCkjJpnYqI 75GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787539245; x=1788144045; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=PFgu3uI6WNJeyj2BeGtQJ3I+sGN1TGHV3G/Qfqx6y0g=; b=FJI7JWs4owznmYxm5RpuPJQ0XXKfQFVSQJmC9n4Y+vfUoAWTROb1T/NDkNdtTpLbtd qPvOYtljChdcfgPMBqctrLA/j2SNEiylQIyiH1YlG7Pd5VRZCNv52MImdezHNdTWSC43 /Tnu0mHMJLDSWafSbdUPURUf5Ue6dpQV4w4+lKriaHdSryiHEf4TDTqls8q/Jwu9nmLV NqkxR+sZcc8e+ui0F9vM6rmDASJu4ittflsm2lPvRImH9Ckf4oUNG0IIm6iGaVQe7B2o dh93TsMfFskyADJfGa6QI84YjiLsqGABfG+LMKPU/pAB5ziOKCZJYvFzuKOXIyF1tYTy WSfQ== X-Forwarded-Encrypted: i=1; AHgh+RomPzxGY8JgDs62RQLzEPczl4VU6o5Nk+3N+OJuvXabqE8OPAzKm5QHChf29n13fYnza4B7LL3M9FwBFM8=@vger.kernel.org X-Gm-Message-State: AFuF++nb/JXq7AZdK/dv+xSfjTwW3YDG5j8jFDx+evLdGau4FRcdmeJh 1W3Kl3Y4d8w2W/twR9f8RwMc3dsOSpSLJTVwJBYQxIQgirMrXymfuMqsbRMBu7ik+M0= X-Gm-Gg: AR+sD10qqoyA1ayD8mSPo/+2f2cgmJeVTmn09kTQKbwpVVOWhst09SNgmXydqVgpCE1 pVPquxcihXbIRQnjBbhrXj8i3yN3vwSiM+MXETmDB2HHoPkkP+pnUuJZY2ewVBR6UnJRif+kIf2 siddMMKUMtxXMZIJKG8po8dP1bZVlpDQWBE7U1iWkUZEuf5pei8GOyUP0tr/F6t9Y9m/u0KJMRQ yRO0wyswCWuC3ElSlBprScdrPeLs+Xmg/p5j+3xdiBjh8chusmFvMJT7RksSK7akG6DKCcK++GC R2Y+EvtEJFgBfIKdMjivC5RMubcEgi8qVdK8NCCtCdUE+K4xPV1fjYusbTzgE920h/ihoGBHwjh FFADksEFAi0Rr74UsqLysGqjFqv0+hWAdXBtQjmoQCdEaVNZVt7wObsoIVeNDRoKGqKbkHbEnRQ Pl2uAFT/pUa74uTiusX8qvkETMy6DFqlHGOnhCxIqnxmyMB8R5xBKTfExM X-Received: by 2002:a17:907:1c9e:b0:c16:3187:997e with SMTP id a640c23a62f3a-c246a4ede76mr2414805966b.7.1787539245600; Sun, 23 Aug 2026 19:40:45 -0700 (PDT) Received: from ownbook ([195.181.160.194]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24966f8f2asm1051909566b.36.2026.08.23.19.40.41 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 23 Aug 2026 19:40:45 -0700 (PDT) From: Aleksei Sviridkin To: Andrew Lunn , Heiner Kallweit , Russell King Cc: Aleksei Sviridkin , Vladimir Oltean , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next v2 2/2] net: phy: restore the interrupt after a generic-driver bind cycle Date: Mon, 24 Aug 2026 05:40:28 +0300 Message-ID: <20260824024029.41310-3-f@lex.la> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260824024029.41310-1-f@lex.la> References: <20260824024029.41310-1-f@lex.la> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A PHY with no specific driver available at attach time gets the generic one, and phy_probe() parks it in polling mode because that driver has no interrupt callbacks. phy_detach() releases the generic driver so a real one can bind later, but the interrupt is not given back, and a generic probe that fails leaves the PHY the same way without reaching phy_detach() at all. The specific driver then attaches with irq =3D=3D PHY_POLL and the PHY stays polled for the rest of the uptime, with no warning on that path. Take it back from the MDIO bus interrupt table on both exits from the cycle: the cycle does not touch that table, so whatever the bus recorded there still stands. A bus that never filled it has nothing to give back and its PHY stays polled. Restore only where the cycle left PHY_POLL, so that an interrupt mode installed on the attached PHY afterwards is not reset. Signed-off-by: Aleksei Sviridkin --- The cycle is easy to hit on a DSA switch that probes before the rootfs is mounted: the switch connects its user ports during setup, the PHY driver is still a module on that rootfs, so the generic driver binds and is released again when the connect fails. The real driver binds at ifup and gets irq =3D=3D PHY_POLL. Both exits from the cycle need the restore: phy_detach() for a generic driver that bound and is being released, and phy_attach_direct()'s error_module_put label for a generic probe that failed, which never calls phy_detach() at all. What the table covers and what it does not. Nothing writes mii_bus->irq[] after the bus is registered except stmmac_mdio.c and mlxbf_gige_main.c, and both assign the same value to phydev->irq in the same breath, so a PHY whose interrupt came from firmware is fixed here. A PHY handed its interrupt by its MAC driver is not: lan78xx and smsc95xx write phydev->irq after registration and leave the table alone, so they keep polling after a generic cycle exactly as they do today, and the set of drivers that write only phydev->irq is larger than those two. Which raises a question I would rather ask than settle alone: if bus->irq[] is the per-address registry for a bus, should those drivers be mirroring into it the way mlxbf_gige and stmmac already do? If that is the intent I am happy to send it as a follow-up. What the guard distinguishes and what it does not. It preserves an interrupt mode installed on the attached PHY after connect, so PHY_MAC_INTERRUPT from genet, tsnep or bcmasp survives the detach. It cannot tell phy_probe()'s parking from the other ways phydev->irq reaches PHY_POLL, so a PHY parked by PHY_F_NO_IRQ, by a failed phy_request_interrupt(), or by a MAC taking the phy.rst advice to set PHY_POLL, is restored here as well. That is harmless for the drivers that do so today: phy_attach_direct() applies PHY_F_NO_IRQ again on the next attach, a failed request is simply retried, and every MAC that forces PHY_POLL does so in the same function that connects the PHY, so a restored value is overwritten before anything can act on it. The guard is not only tidiness. Without it a PHY that a MAC had put in PHY_MAC_INTERRUPT mode would get a real interrupt number back at detach, the next phy_connect_direct() would request it, and phy_disconnect() would then skip phy_free_interrupt(), because the MAC overwrites phydev->irq again right after connect and phy_interrupt_is_valid() is false by the time the interrupt would be freed. That asymmetry between phy_connect_direct() and phy_disconnect() is not new, and it bites any such MAC whose PHY has an interrupt to request; the guard keeps a generic-driver cycle from walking a PHY into it. The same interrupt is also lost on a plain sysfs unbind and rebind of a PHY driver, and this patch does not cover that. A restore in phy_remove() would cover both paths, but is_genphy_driven is what keeps the intent narrow here, so I would rather not widen the fix on a guess. No Fixes: tag on this one. The behaviour predates what I can bisect in this tree; if someone can name the commit I will add it. drivers/net/phy/phy_device.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 94b2e85e00a3..8c93d35e1c94 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1734,6 +1734,18 @@ static bool phy_drv_supports_irq(const struct phy_dr= iver *phydrv) return phydrv->config_intr && phydrv->handle_interrupt; } =20 +/* Give back the interrupt phy_probe() parked when a driver with no interr= upt + * callbacks bound. The bind cycle does not touch the bus interrupt table,= so + * whatever the bus recorded there still stands; a bus that never filled i= t has + * nothing to give back. Only the parking is undone: any other value the P= HY + * carries was put there by someone else. + */ +static void phy_restore_genphy_irq(struct phy_device *phydev) +{ + if (phydev->irq =3D=3D PHY_POLL) + phydev->irq =3D phydev->mdio.bus->irq[phydev->mdio.addr]; +} + /** * phy_attach_direct - attach a network device to a given PHY device point= er * @dev: network device to attach @@ -1896,6 +1908,7 @@ int phy_attach_direct(struct net_device *dev, struct = phy_device *phydev, =20 error_module_put: module_put(d->driver->owner); + phy_restore_genphy_irq(phydev); phydev->is_genphy_driven =3D 0; d->driver =3D NULL; error_put_device: @@ -1965,6 +1978,7 @@ void phy_detach(struct phy_device *phydev) * real driver could be loaded */ if (phydev->is_genphy_driven) { + phy_restore_genphy_irq(phydev); device_release_driver(&phydev->mdio.dev); phydev->is_genphy_driven =3D 0; } --=20 2.55.0