From nobody Sat Sep 26 23:52:23 2026 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 60D8139A057 for ; Fri, 28 Aug 2026 09:22:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787908954; cv=none; b=QTU2OmJjdBGkBFB0naDYENDSkMWr5dsNciX0R9umkFb9mT5pngTKwLNK4vwEQ541jJR5tUG2SKoLfT/w426yPAEmZiONqQwewSHpxNk/zX8wv6kYKFv6eOr/GvVq9NIl5A4WEyJs/kx0wSqvz+1RrXW7Miq879BnXMDn3qVJBEk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787908954; c=relaxed/simple; bh=vKv+GXIuyE2hiDyG1h0rqn+IWb8EjWtNu3co1fIZfgY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IwEHGejX1DkmJ89H7nWoBfwZ8uLPJ1MUwCBnAYOgpeLE2Q3w49JKD3JmhvnSnUKVxCrNNoJHv4waLQe00wKgsZQ9BfNlCDiuRqWiHo/BjlFxE3wP8C6TJB69JGD0pIVzeuGCaVvMDlktb9t8ej7GHX4zvblAwNlgSdUbWy0k5IM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=iit.org.ua; spf=pass smtp.mailfrom=iit.org.ua; dkim=pass (2048-bit key) header.d=iit.org.ua header.i=@iit.org.ua header.b=iY+eyMjv; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=iit.org.ua Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iit.org.ua Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=iit.org.ua header.i=@iit.org.ua header.b="iY+eyMjv" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49b96837ca3so2778385e9.3 for ; Fri, 28 Aug 2026 02:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iit.org.ua; s=google; t=1787908949; x=1788513749; 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=0x/pbKOdcSa5MoWBFxRhYpy2xSpaLcp53m9A0z28vvY=; b=iY+eyMjvfLzs6mBRq6QzAXPBKMR8uLSK2+efwCdmDBl4YkFb6vN1hMMptZCNGw+EMa vqiZ/1EbQfOU9HU+lGku1y5iSosIo/s4EoCVgL9tiX4Ui5agUGESSFWQgDNGNkdQ/YeH zOOj0mEkwd6zCPytVw3tTDO9kSIJhquM7AOTaemFcd8b+x1AJ10+NjMmS72hZ1qkrjmq gNQMCYG8y8r97hClDNCVAu6RyzPMtgFNuVYL3C4wjyOiBDbR8yGzRwXj6Sha4O//wW8q GlW1HDBfgJ6sizSBr/KI85vveBbuymIIIZp4YnoIKdoewaTknHWwm2ShD37Y5yMdGZGj R++Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787908949; x=1788513749; 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=0x/pbKOdcSa5MoWBFxRhYpy2xSpaLcp53m9A0z28vvY=; b=kr8lf0SPQDmWjWx8I44QCp2p9sJZXUqzB1Ht1rtTJZV19a+tnRUmbJnvppjgceGyvS udfp2yFtF8oczI26/DEQwEu8NQPsrIry3fz00CRQSvVFkAcPyYXDo0ux5hIxCXp+kmUe K2a4CTbWMr4aM6B48dHz3wgM/XjYkRXreKzfej221riL0+NfiRGDAuZHjSbytmlh/5qq j4IQe4Wb74kGqYJUiCQZJCefi00OaVpaRB4kHTHTcnhOmrnxh578P4/BeWiTGNQF7E5N O0DhgJrXknzHP3V9jTJS013vw56eSkupjni6ioH+BiFgQvNhfxk9KsR4lhoGjww5+idq /1Dg== X-Forwarded-Encrypted: i=1; AHgh+Rro97n7YPuBHkob/q2NmOi9tJO1XHsuZrDD/a171hAtf1wfpIekH8LASrDMzuvoGMl2ZncxSobHjkem9HI=@vger.kernel.org X-Gm-Message-State: AFuF++k1t5hfko8N36WrlEozVVmhdGDfUksW5KmP5PKarqJdejMN03hV 0avIwmq3vf/ozKssT6xzvnD0E/7B12Dja4Nm5xN5JvS7OtEYkIKs4yBJBlOiubXQPrY= X-Gm-Gg: AR+sD13gQXCW269ixnvc8CK7RHBRVchd49Qmb2ZNF9c+bwSbzZ3mPNop/7sE9MU16xL E3vCddor2F50yDoPxN+SXOf0tfVG516KA5CdsfEaowB63Brc+e2V9RtVQrnwj7XC0PTCzV0c/MY IYRAnC/JegtiSviojgoMVhPNo7vX5i7M2oiLXMKmhV8m9EEqb0M2IkQM03CFmaqUqqJfbcgzGzM bjVbYo2GZSVI9TZ/HG6UXBZacltYsKa0Eq34C5ZMvGXuXPpz3RuUrK70MR7+iKDVlsjJ2VN9PfW CCiBJ8kSKdZ8gTZbDqXfqUqFF8j1esNPrZFzyt3Sc1iTjzBLDdRniuosSaI2dFhmX80E4UcS/pw 0MbDJqvXBlXFzRErPjdm9ZyyFvx/6V4hVsQwGwOQkAEk8vnbAH4b1wCF7WQMoUsoJf8qxQeZHTn GN+UbCZIBBswl6+xfKr4dhy0J3MeWqrDaYbjYTyUGGPs/zyGApWJe2yA== X-Received: by 2002:a05:600c:5487:b0:495:7888:281c with SMTP id 5b1f17b1804b1-49b91bd1463mr61514445e9.0.1787908949656; Fri, 28 Aug 2026 02:22:29 -0700 (PDT) Received: from archbtw ([212.1.106.18]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b497fa9c5sm111484255e9.4.2026.08.28.02.22.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Aug 2026 02:22:29 -0700 (PDT) From: Stepan Svatenko To: Raju.Rangoju@amd.com, PrashanthKumar.K.R@amd.com Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Stepan Svatenko , stable@vger.kernel.org Subject: [PATCH net 1/2] amd-xgbe: fix comm_ownership mutex deadlock on SFP module removal Date: Fri, 28 Aug 2026 12:20:22 +0300 Message-ID: <20260828092023.105405-2-ssvatenko@iit.org.ua> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260828092023.105405-1-ssvatenko@iit.org.ua> References: <20260828092023.105405-1-ssvatenko@iit.org.ua> 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" xgbe_phy_sfp_detect() acquires xgbe_phy_comm_lock (via xgbe_phy_get_comm_ownership()) and holds it across calls that can end up freeing the external PHY device: xgbe_phy_sfp_detect() xgbe_phy_get_comm_ownership() <- mutex_lock xgbe_phy_sfp_mod_absent() / xgbe_phy_sfp_read_eeprom() (SFP changed) xgbe_phy_free_phy_device() phy_detach() phy_suspend() genphy_suspend() xgbe_phy_mii_read_c22() <- mii_bus->read xgbe_phy_get_comm_ownership() <- mutex_lock again xgbe_phy_comm_lock is a plain, non-recursive mutex. phy_detach() ends up calling back into this driver's own MDIO bus callbacks (xgbe_phy_mii_read_c22()/xgbe_phy_mii_write_c22(), reached via genphy_suspend() during phy_detach()), which independently acquire the same lock, so the second acquisition deadlocks the task tearing down the SFP module. This is reliably reproducible by removing an SFP module while an external PHY is attached: the removal handler hangs forever inside xgbe_phy_free_phy_device(), confirmed via /proc//stack and the kernel hung-task detector (blocked 368s+). Reproduced on a SolidRun Bedrock V3000 (AMD Ryzen Embedded V3C48). There were two call paths into xgbe_phy_free_phy_device() while the mutex was held: the module-absent path, and a second one inside xgbe_phy_sfp_read_eeprom() when the EEPROM contents change (e.g. a module swap). Fix this by never calling xgbe_phy_free_phy_device() (directly, or via xgbe_phy_sfp_mod_absent()) while holding xgbe_phy_comm_lock. xgbe_phy_sfp_read_eeprom() no longer frees the PHY device itself; it only records that the SFP changed. xgbe_phy_sfp_detect() releases the mutex before calling xgbe_phy_sfp_mod_absent() or xgbe_phy_free_phy_device(), and re-acquires it only around the remaining raw I2C access in xgbe_phy_sfp_external_phy(). Neither xgbe_phy_sfp_mod_absent() nor xgbe_phy_sfp_parse_eeprom()/ xgbe_phy_sfp_phy_settings() touch hardware directly, so they don't need the mutex held. Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") Cc: stable@vger.kernel.org Signed-off-by: Stepan Svatenko Assisted-by: Claude Code:claude-sonnet-5 [Bash] [Read] [Edit] --- drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 41 ++++++++++++++++----- 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c b/drivers/net/ethe= rnet/amd/xgbe/xgbe-phy-v2.c index 59a074ed312a..a264ec5bb085 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c @@ -1218,7 +1218,13 @@ static int xgbe_phy_sfp_read_eeprom(struct xgbe_prv_= data *pdata) goto put; } =20 - /* Check for an added or changed SFP */ + /* Check for an added or changed SFP. Freeing any existing external + * PHY device is deferred to the caller: xgbe_phy_free_phy_device() + * can end up calling back into this driver's MDIO read/write + * routines (via phy_detach() -> phy_suspend()), which take the + * comm ownership mutex themselves, and that mutex is held across + * this call. + */ if (memcmp(&phy_data->sfp_eeprom, &sfp_eeprom, sizeof(sfp_eeprom))) { phy_data->sfp_changed =3D 1; =20 @@ -1226,8 +1232,6 @@ static int xgbe_phy_sfp_read_eeprom(struct xgbe_prv_d= ata *pdata) xgbe_phy_sfp_eeprom_info(pdata, &sfp_eeprom); =20 memcpy(&phy_data->sfp_eeprom, &sfp_eeprom, sizeof(sfp_eeprom)); - - xgbe_phy_free_phy_device(pdata); } else { phy_data->sfp_changed =3D 0; } @@ -1296,26 +1300,45 @@ static void xgbe_phy_sfp_detect(struct xgbe_prv_dat= a *pdata) /* Read the SFP signals and check for module presence */ xgbe_phy_sfp_signals(pdata); if (phy_data->sfp_mod_absent) { + /* xgbe_phy_sfp_mod_absent() calls xgbe_phy_free_phy_device(), + * which can call back into this driver's MDIO read/write + * routines via phy_detach() -> phy_suspend(). Those routines + * take the comm ownership mutex themselves, so it must be + * released before making this call. + */ + xgbe_phy_put_comm_ownership(pdata); xgbe_phy_sfp_mod_absent(pdata); - goto put; + goto settings; } =20 ret =3D xgbe_phy_sfp_read_eeprom(pdata); + xgbe_phy_put_comm_ownership(pdata); if (ret) { /* Treat any error as if there isn't an SFP plugged in */ xgbe_phy_sfp_reset(phy_data); xgbe_phy_sfp_mod_absent(pdata); - goto put; + goto settings; } =20 + /* Same reasoning as above: this must run without the comm + * ownership mutex held. + */ + if (phy_data->sfp_changed) + xgbe_phy_free_phy_device(pdata); + xgbe_phy_sfp_parse_eeprom(pdata); =20 - xgbe_phy_sfp_external_phy(pdata); + /* Re-acquire ownership for the external PHY access below; it talks + * to the SFP over I2C directly and needs the mutex held again. + */ + ret =3D xgbe_phy_get_comm_ownership(pdata); + if (!ret) { + xgbe_phy_sfp_external_phy(pdata); + xgbe_phy_put_comm_ownership(pdata); + } =20 -put: +settings: xgbe_phy_sfp_phy_settings(pdata); - - xgbe_phy_put_comm_ownership(pdata); } =20 static int xgbe_phy_module_eeprom(struct xgbe_prv_data *pdata, --=20 2.55.0 From nobody Sat Sep 26 23:52:23 2026 Received: from mail-wm2-f1.google.com (mail-wm2-f1.google.com [74.125.225.129]) (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 6097739B96A for ; Fri, 28 Aug 2026 09:22:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.129 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787908976; cv=none; b=jisG3E0uBcerDqfDxI0SQSj9eC9hqCI9S2QWPJFytKqA2GWce7uBbYTo97Ii4BRScEUwDS70LCLeF/hkYOc5MCt6WPjBGNfNlZOrfTPoId9Nusk0EBnkEstAy7aS5TcSCGT1YJWzSwE7zgtfdxPSn3nS0pz/0GVoQ6GtXVSZgQ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787908976; c=relaxed/simple; bh=ey7QBCaDld1Q/XVKLLwtP0hYutZJghLE6jPBnqkv3CE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=syy8c/YlDzHZwcwSv7O21xi1AtW1A5cbz+01tlCLhOwgUHnM4jYvtbgi0V4RiTl1bBbyBdQwA+pemCi1WPJx6/mV8o1G7OFkqrO8/sWHTnST4zBgfceLkLAMTu4wwYm2H28W+mk3czEqOvDip4v9zfhkpfR/BO9i+tja0IRJ74Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=iit.org.ua; spf=pass smtp.mailfrom=iit.org.ua; dkim=pass (2048-bit key) header.d=iit.org.ua header.i=@iit.org.ua header.b=u4IrY0Z6; arc=none smtp.client-ip=74.125.225.129 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=iit.org.ua Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iit.org.ua Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=iit.org.ua header.i=@iit.org.ua header.b="u4IrY0Z6" Received: by mail-wm2-f1.google.com with SMTP id 5b1f17b1804b1-492367f3094so2109935e9.0 for ; Fri, 28 Aug 2026 02:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iit.org.ua; s=google; t=1787908972; x=1788513772; 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=/oMl6tXRVOo96S1AJPzpgtCrziqZeX/47A+u1zT3/48=; b=u4IrY0Z6hqWgpA1FMsAbYBIcOgHWh7Nk0FJXvpNEYfcCEWAS2WAV3CVQ24LgDm+Q0F hvE+QaUyE+AS+eQhAQ5XCxC3Gme54/cnzvun9C4EcjGTHRMB21pEN6duj+XGcdV8sV71 DSknZ27sYfUghik0ypBqjqTSMVfFp2V+2vRs4prCSYkMzrM1eT01oLfS9R2fuQvd22IH 7GB0HSZzyyVTlDBKTsXOAP6t/ndpl97rR4EQceDsS3hCxd/rG85tm4tdx2l9XDwjPVox LN2GPJh4hRBz+qtoQSaBUiJT9BeIzg6rS9UVgdjZEgsZYtvROG8a5OxSTgDzHZaZDdvq g/pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787908972; x=1788513772; 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=/oMl6tXRVOo96S1AJPzpgtCrziqZeX/47A+u1zT3/48=; b=TYlv5lG+tIW6Xe/7h+QXwraYc8Yb5wgG4mYNDeGLJbFRhJeKQHtu7vdfVH8c4ATRfe 1+73HyFFHUlijxXB9FhPVS8mfKciGb7G1lOmr9eTaw7EkL3pCLMHKsSAiScNmhbQTRk5 ybaEOkANIG17Jl5GW1HbrJomErU3dPiDaDIgpf/hwZoK26FYquKIPiqnnj8fjwK0QRW7 NifCEkKozJVLFKsOSgzB+wegu+hh+qYsTTkKja1Y1gzQv0ZwsFbnJZV4NrNdjvE+I1uI SkJEJU4xkGclRO05LM0SJS8q0/6jorbqN2Ei0/Xj0V4XezwuTgmR+w2PnEqogZ5/my36 nYgw== X-Forwarded-Encrypted: i=1; AHgh+RrZDnWsQId0cTlCcR+8P4ZqWap8InXPG91wSBaYtsWzux8X91P64EZwXRm0/kzcE1nyiSzZ067iKF7fNLI=@vger.kernel.org X-Gm-Message-State: AFuF++m7wTSP5MivqjLONbn2ibcHtwuRwY55jTZrZg2MZPUaizG3+onT ex9kJdaDVQcZaJmYpCjimSZ04yeSpyDzsPIG3HMghaHcRbyrX0TVjW/hyoVP5ryeyUKtThnovKW m+hZ9k/lAi5zV X-Gm-Gg: AR+sD112vi0BmkgXNuTyShzVupiSdld5PW6WO0sLxxFj9BXt7qUAp+2GbBG8JvmEI6T 2EUNMYgaby+9W2PD9rrTfiv+PJIRR5FMzFBhB0Vsiol1ylMmpsiz9S7lesXRszAn2AjpHa4lr7I kBs8n7tnxLSjLYD9fto071HJyNmIC6HorgsPWVGNR0m1om3u201yXD4hjWnX4pVKttI0rgT3dKi Cf3cQCT+DV6mYKV+jyBkJgpXRK+sgI148M9rDjcj2FuHwXUCgCSIkIaI5VQcJ9zNiJIu4nLy/TM 7KYyM0X+LBhd8VCzjpyzHRQEYrFgSLZWX7TF9UVPpoCXHKvsYEkHyBd36n303v2BBxogdKM3VC1 IVo4Gv6KIjyG9E7ous8YWBHWyq1MuuWb+kWb2dracoRoPU3civVDerOS5DsVXOUgoA3rj4K1l2b TCNejp0EZwGnjOaB8bu3L/Fls4CT5syDOyjCeQoTQMXC68euOpckWdqA== X-Received: by 2002:a05:600c:45d4:b0:499:7219:122f with SMTP id 5b1f17b1804b1-49b91c1ebd7mr67005445e9.4.1787908972528; Fri, 28 Aug 2026 02:22:52 -0700 (PDT) Received: from archbtw ([212.1.106.18]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b497fa9c5sm111484255e9.4.2026.08.28.02.22.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Aug 2026 02:22:52 -0700 (PDT) From: Stepan Svatenko To: Raju.Rangoju@amd.com, PrashanthKumar.K.R@amd.com Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Stepan Svatenko , stable@vger.kernel.org Subject: [PATCH net 2/2] amd-xgbe: fix an_irq leak causing permanent -EBUSY on PHY (re)start Date: Fri, 28 Aug 2026 12:20:23 +0300 Message-ID: <20260828092023.105405-3-ssvatenko@iit.org.ua> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260828092023.105405-1-ssvatenko@iit.org.ua> References: <20260828092023.105405-1-ssvatenko@iit.org.ua> 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" xgbe_phy_start() requests the separate AN/PCS interrupt (an_irq) and, on any failure past that point, is expected to free it again via the err_irq/err_stop labels before returning an error. The last error path skips that cleanup: pdata->phy_started =3D 1; xgbe_an_init(pdata); xgbe_an_enable_interrupts(pdata); return xgbe_phy_config_aneg(pdata); <- returns directly on error xgbe_phy_config_aneg() (via __xgbe_phy_config_aneg()) can genuinely fail, e.g. when phy_impl.an_config() fails against a non-functional SFP module. When it does, xgbe_phy_start() returns that error without going through err_irq/err_stop, so: - an_irq is never freed with devm_free_irq(), and - pdata->phy_started is left set to 1, even though the caller (xgbe_start()) now treats this as a failed start and does not call phy_if->phy_stop() itself on that path. Any later retry of xgbe_phy_start() (interface bring-up retried by userspace, or the driver's own recovery logic) then calls devm_request_irq() for the same still-registered an_irq and gets -EBUSY every time, with no way to recover short of a reboot/power cycle: genirq: Flags mismatch irq 63. 00200000 (enp8s0f3-pcs) vs. 00200000 (enp8= s0f3-pcs) amd-xgbe 0000:08:00.3: error -EBUSY: request_irq(63) xgbe_an_isr [amd_xgb= e] 0x0 enp8s0f3-pcs amd-xgbe 0000:08:00.3 enp8s0f3: phy irq request failed Reproduced on a SolidRun Bedrock V3000 (AMD Ryzen Embedded V3C48) by inserting a non-functional SFP module, then bringing the interface up. Fix this by routing the xgbe_phy_config_aneg() failure through xgbe_phy_stop(), which already contains the correct, symmetric teardown (disables AN, frees an_irq if separate, cancels the bh work, stops the PHY implementation) and is safe to call here because it is gated on pdata->phy_started. Fixes: 7c12aa08779c ("amd-xgbe: Move the PHY support into amd-xgbe") Cc: stable@vger.kernel.org Signed-off-by: Stepan Svatenko Assisted-by: Claude Code:claude-sonnet-5 [Bash] [Read] [Edit] --- drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c b/drivers/net/ethern= et/amd/xgbe/xgbe-mdio.c index 12770af031eb..638c24b9c83c 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c @@ -1445,7 +1445,19 @@ static int xgbe_phy_start(struct xgbe_prv_data *pdat= a) xgbe_an_init(pdata); xgbe_an_enable_interrupts(pdata); =20 - return xgbe_phy_config_aneg(pdata); + ret =3D xgbe_phy_config_aneg(pdata); + if (ret) { + /* Tear down what was just brought up above (including + * freeing the an_irq) instead of returning with phy_started + * left set and an_irq still registered - otherwise a retry + * calls devm_request_irq() on an already-owned an_irq and + * gets stuck in a permanent -EBUSY loop. + */ + xgbe_phy_stop(pdata); + return ret; + } + + return 0; =20 err_irq: if (pdata->dev_irq !=3D pdata->an_irq) --=20 2.55.0