STRUCT PHY_PORT(9)

✨ struct phy_port(9) ✨

the kernel API manual, section 9 — bestie edition 🫶

okay so picture this: it's a whole struct in the kernel that's basically the main character representation of a network device's physical interface. like, the actual pluggy-inny port part, not the whole device. she's serving hardware-truth realness 💅 and honestly? iconic.

---

🎀 NAME 🎀

struct phy_port — no cap, this is literally a representation of a network device physical interface. that's it, that's the vibe check ✨

---

🌸 SYNOPSIS 🌸

here's the whole glow-up, copy-pasted from the source exact-exact, so you know it's real:

struct phy_port {
    struct list_head head;
    enum phy_port_parent parent_type;
    union {
      struct phy_device *phy;
    };
    const struct phy_port_ops *ops;
    int pairs;
    unsigned long mediums;
    unsigned long supported[BITS_TO_LONGS(
__ETHTOOL_LINK_MODE_MASK_NBITS)];
    unsigned long interfaces[BITS_TO_LONGS( PHY_INTERFACE_MODE_MAX)];
    unsigned int not_described:1;
    unsigned int active:1;
    unsigned int is_mii:1;
    unsigned int is_sfp:1;
 };

look at all those bitfields at the bottom though — :1 after :1 after :1, she is packed, she is efficient, she is not wasting a single bit 😭👑

---

🦋 Members 🦋

okay bestie, let's go through every single one of her fields because we do NOT skip members in this house 💖

• head — the port's parent uses this to keep her in a list of ports. it's giving group-chat member list energy. she's listed 💀
• parent_type — tells you the type of device this port is directly connected to. like, who's your parent? what's the family tree situation? 🌳
• {unnamed_union} — it's an anonymous union, no name, no label, just vibes. she's mysterious like that 🙈
• phy — if the parent happens to be PHY_PORT_PHYDEV, this is the PHY controlling that port. lowkey the only time she shows up to the party ✨
• ops — the callback ops, implemented by the port controller. this is where the port controller gets to show off its tricks 🎪
• pairs — the number of pairs this port has, and it's 0 if that concept doesn't even apply. not every port is a pairs girly 💅
• mediums — a bitmask of the physical mediums this port provides access to. bitmask baddie 💅
• supported — the link modes this port can expose — but only if this port is MDI (not MII). MDI girlies only, sorry MII 😌
• interfaces — the MII interfaces this port supports, if this port is MII. the flip side of the coin, we love a matching set 🦋
• not_described — signals to the parent driver that this port isn't described, which means it's fully up to the parent to filter its capabilities. no description? no problem, parent's problem now 😭
• active — says whether the port is currently part of the active link. is she in the link or is she just lurking? main character check ✅
• is_mii — tells you if this port is MII (Media Independent Interface) or MDI (Media Dependent Interface). pick a lane bestie, the acronyms are fighting 💀
• is_sfp — says if this port drives an SFP cage. cage driver energy, lowkey feral 🔥

---

🌈 SEE ALSO 🌈

• Kernel file ./include/linux/phy_port.h
• enum phy_port_parent(9)

go read those next, iyktyk, they're the prequel 🎀

---

fr fr bestie, that's the whole struct — every field, every bitfield, every anonymous union. don't @ me if your parent driver forgets to filter capabilities when not_described is set, that's a you problem 😭💜

and that's the tea, signed off from the ./include/linux source tree, dated October 2026, struct phy_port(9) forever and always 🫶✨