phy_of_parse_port(9)

📦 version 7.3.1, in nixpkgs unstable

💅 phy_of_parse_port(9) — the kernel manual, but make it make sense ✨

okay so bestie, welcome to phy_of_parse_port from the Kernel API Manual, i.e. the (9) section, which is lowkey the "kernel internals" shelf of the library. this one's a little constructor function and it's honestly so straightforward it ate. let me walk you through it 🫶

🌸 NAME 🌸

phy_of_parse_port — literally just: create a phy_port from a firmware representation. that's the whole vibe. you hand it firmware data, it hands you back a port. iconic behavior, no notes 💖

✨ SYNOPSIS ✨

struct phy_port * phy_of_parse_port (struct device_node *dn );

yes that's the whole signature, she's short and she knows it 💅

🎀 ARGUMENTS 🎀

  • dn — the device_node representation of the port, and it's supposed to be following the ethernet-connector.yaml binding. so like, if your firmware node didn't read the assignment, that's on you bestie 🙈

🔥 RETURN 🔥

it gives you back a newly allocated and initialized phy_port pointer. slay. but — and this is the important part, don't skip it — it can also return an ERR_PTR. so fr fr, check that pointer before you go dereferencing it, because an ERR_PTR is not a port, it's a little "nope" wrapped in pointer clothing 💀

🦋 SEE ALSO 🦋

the kernel file ./drivers/net/phy/phy_port.c plus the whole friend group:

like, go read those too, they're all part of the same lore iykyk 📚

⭐ little recap because i love you: parser in, phy_port out, and always vibes-check for ERR_PTR before using it. no cap.

this page lives over in ./drivers/net/phy, and it's dated October 2026 — that's the source/version and date energy right there. mwah, bye bestie 💜✨🎀

📦 where this page comes from