phy_get(9)

📦 version 7.3.1, in nixpkgs unstable

💅 phy_get(9) — from the Kernel API Manual, bestie 🎀

Okay so real talk, this is a page out of the Kernel API Manual, and it's about one tiny little function that does one huge job: grabbing you a phy and holding onto it. No cap, it's giving "let me introduce you to your new phy" energy.

✨ NAME ✨

phy_get — lookup and obtain a reference to a phy. 🦋

Like, it goes and finds the phy for you and then keeps a little counter so nobody yanks it away while you're using it. Iconic behaviour honestly.

🌸 SYNOPSIS 🌸

struct phy * phy_get (struct device *dev , const char *string );

That's the whole vibe. Two args, one struct phy * back. Periodt. 💅

🎀 ARGUMENTS 🎀

  • dev — the device that requests this phy 👑 — like, this is the one asking, so the kernel knows who's claiming it.
  • string — the phy name as given in the dt data, or the name of the controller port for the non-dt case ⭐ — two ways to say who you want, depends on whether you're living that device-tree life or not.

🔥 DESCRIPTION 🔥

So here's the tea: phy_get returns the phy driver, after getting a refcount to it 🫶 — or it hands you back -ENODEV if there is no such phy 😭. Meaning: if it exists, it's yours (with a nice little reference count holding it in place). If it doesn't exist? You get -ENODEV and you deal with it.

⚠️ Important bestie note: the caller is responsible for calling phy_put to release that count. Do not forget. That refcount is not gonna release itself, and leaking it is not the main character move you think it is 💀.

🌈 SEE ALSO 🌈

Kernel file ./drivers/phy/phy-core.c — that's the source, go read it, it's literally right there iykyk 📖

And the whole friend group of related calls, because phy_get never travels alone:

That's the whole page, bestie, you ate it up 💖✨

🌟 Cute lil sign-off: this one lives in ./drivers/phy, dated October 2026. Go forth and phy_put responsibly 🧚💜
📦 where this page comes from