These two bugs were found while debugging SFP-related failures on a
SolidRun Bedrock V3000 (AMD Ryzen Embedded V3C48), on kernels 6.15.5,
6.18 and 7.0. Both are longstanding (dating back to when the affected
code was originally added) and independent of each other, but touch
related PHY/IRQ lifecycle paths in the same driver, so sending them
together:

  1/2 fixes a self-deadlock: xgbe_phy_sfp_detect() holds
      xgbe_phy_comm_lock across a call chain that can re-enter the
      driver's own MDIO read/write callbacks, which take the same
      mutex. Triggered by removing an SFP module while an external
      PHY is attached; confirmed hung via the kernel hung-task
      detector (368s+ blocked).

  2/2 fixes an IRQ leak: xgbe_phy_start() can return an error after
      already registering its AN/PCS interrupt, without freeing it
      or clearing state, if xgbe_phy_config_aneg() fails (e.g.
      against a non-functional SFP module). Any later retry then
      hits -EBUSY requesting the same still-registered IRQ forever,
      with no recovery short of a power cycle.

Both were hardware-tested on a SolidRun Bedrock V3000 running 6.15.5
with these fixes applied: repeated SFP insert/remove and interface
up/down cycles, including with a non-functional module, no longer
trigger the hang or the -EBUSY loop. The code paths touched by both
patches are byte-for-byte unchanged between 6.15.5 and the tree this
series is generated against, so the same fix applies directly here.

Stepan Svatenko (2):
  amd-xgbe: fix comm_ownership mutex deadlock on SFP module removal
  amd-xgbe: fix an_irq leak causing permanent -EBUSY on PHY (re)start

 drivers/net/ethernet/amd/xgbe/xgbe-mdio.c   | 14 ++++++-
 drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 41 ++++++++++++++++-----
 2 files changed, 45 insertions(+), 10 deletions(-)

--
2.55.0