phy_sfp_detach(9)

📦 version 7.3.1, in nixpkgs unstable

✨ phy_sfp_detach(9) ✨

okay so we're in the Kernel API Manual bestie, and today's main character is phy_sfp_detach(9) 💅 no cap, she's a tiny little cleanup function but she MATTERS.

🌸 NAME 🌸

phy_sfp_detach — detach the SFP bus from the PHY upstream network device 🫶

🎀 SYNOPSIS 🎀

void phy_sfp_detach (void *upstream , struct sfp_bus *bus );

literally that's the whole signature. she takes two things and returns nothing (void), and yes she's one of those functions that exists purely to be a callback. iconic behavior honestly 😭

🦋 ARGUMENTS 🦋

  • upstream — pointer to the phy device ✨ (this is the dev you're passing in, the one on the upstream side — you know the one)
  • bus — sfp bus representing cage being attached 🍓 (yep, that's what the manpage says, cage being attached — keep that energy, iykyk)

💜 DESCRIPTION 💜

So what does she do? She's the designated filler-upper for the sfp_upstream_ops .detach member 🔥. That's it. That's the job. You plug her into that struct member and she handles the detach side of things when the SFP bus needs to come off the PHY upstream network device.

like she's not out here doing the most — she's a callback, she shows up, she does the detach, she leaves 💅 periodt.

ngl this is one of those functions where the manpage description is shorter than this rewrite, so don't go expecting extra lore. everything she does is up in that one sentence 👑

🌈 SEE ALSO 🌈

okay bestie this list is LONG, so buckle up 🎢 — first the kernel file involved:

  • Kernel file ./drivers/net/phy/phy_device.c

and then the whole friend group 💖 (yes, all of them, in order, no skipping):

and that's the whole page bestie, she's short but she's serving 💅 go read phy_sfp_attach(9) next, they're literally a matching set 🫶

source: ./drivers/net/phy · dated October 2026 · the Kernel API Manual said slay and honestly? she did 💖✨🎀

📦 where this page comes from