phy_prepare_link(9)

💖 phy_prepare_link — the Kernel API Manual, but make it a group chat ✨

Okay bestie, so this one's a Linux kernel API manual page for phy_prepare_link(9), and honestly? It's giving "small function, big responsibility." It lives over in ./drivers/net/phy, and it's the vibe-check moment where the PHY layer gets told to keep an eye on the link for you. Let's get into it 🎀

---

🌸 NAME 🌸

phy_prepare_link — literally just prepares the PHY layer to monitor link status. That's it, that's the whole job. Iconic, lowkey, no notes 💅

---

✨ SYNOPSIS ✨

void phy_prepare_link (struct phy_device *phydev , void
(*handler)(struct net_device *) );

So it returns nothing (void), it takes a struct phy_device * called phydev, and it takes a callback — a pointer to a function that receives a struct net_device *. Simple girlie at the surface, but she's doing a LOT behind the scenes. 🔥

---

🦋 ARGUMENTS 🦋

• phydev — the target phy_device struct. Basically the PHY you're telling to get on link-watch duty 💖
• handler — the callback function for link status change notifications. When the link status changes, this is the function that gets called, so make it a good one 🫶

---

🌈 DESCRIPTION 🌈

Okay so here's the tea: this function tells the PHY infrastructure to handle all the gory details of monitoring link status — and yes, it can be doing that either through polling or through an interrupt, so the PHY layer picks how that goes down. Then, whenever the link status changes, it calls back to the connected device driver using your handler. Bestie, it's out here doing the whole monitoring arc so you don't have to. 👑

⚠️ Real talk though — if you want to monitor your own link state, don't call this function. That's not a vibe, that's a conflict of interest. Just stepping aside nicely and letting someone else handle it is the move. This one's not for you if you're the DIY link-monitoring type. 💀

---

💜 SEE ALSO 💜

Kernel file:

./drivers/net/phy/phy_device.c

And the whole extended friend group 👑:

• phy_uses_state_machine(9)
• phy_register_fixup(9)
• genphy_match_phy_device(9)
• get_phy_c45_ids(9)
• get_phy_c22_id(9)
• get_phy_device(9)
• phy_device_register(9)
• phy_device_remove(9)
• phy_get_c45_ids(9)
• phy_find_next(9)
• phy_connect_direct(9)
• phy_connect(9)
• phy_disconnect(9)
• phy_poll_reset(9)
• phy_sfp_connect_phy(9)
• phy_sfp_disconnect_phy(9)
• phy_sfp_attach(9)
• phy_sfp_detach(9)
• phy_sfp_probe(9)
• phy_attach_direct(9)
• phy_detach(9)
• phy_reset_after_clk_enable(9)
• genphy_config_advert(9)
• genphy_c37_config_advert(9)
• genphy_setup_forced(9)
• genphy_restart_aneg(9)
• genphy_check_and_restart_aneg(9)
• __genphy_config_aneg(9)
• genphy_c37_config_aneg(9)
• genphy_aneg_done(9)
• genphy_update_link(9)
• genphy_read_status_fixed(9)
• genphy_read_status(9)
• genphy_c37_read_status(9)
• genphy_soft_reset(9)
• genphy_read_abilities(9)
• phy_remove_link_mode(9)
• phy_advertise_supported(9)
• phy_advertise_eee_all(9)
• phy_support_eee(9)
• phy_disable_eee(9)
• phy_support_sym_pause(9)
• phy_support_asym_pause(9)
• phy_set_sym_pause(9)
• phy_set_asym_pause(9)
• phy_validate_pause(9)
• phy_get_pause(9)
• phy_get_internal_delay(9)
• phy_get_tx_amplitude_gain(9)
• phy_get_mac_termination(9)
• phy_get_sfp_port(9)
• fwnode_mdio_find_device(9)
• fwnode_phy_find_device(9)
• fwnode_get_phy_node(9)
• phy_probe(9)
• phy_driver_register(9)

Like I said — big friend group, lots of lore. Go read them if you want the full cinematic universe 🍓

---

💫 That's the whole page, bestie — short, sweet, and fully link-monitored. 💫

Sign-off time 🎀 — this one's from the Kernel API Manual, living under ./drivers/net/phy, dated October 2026, and it's all about phy_prepare_link(9). Periodt. 💖