ethnl_req_get_phydev(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ethnl_req_get_phydev(9)

okay so bestie, welcome to the Kernel API Manual ✨ this one's from the ethnl_req_get_phydev(9) page and it's literally all about grabbing the phy_device that this request is targeting β€” if there even is one πŸŽ€


🌸 NAME 🌸

ethnl_req_get_phydev β€” Gets the phy_device targeted by this request, if any. πŸ¦‹


✨ SYNOPSIS ✨

struct phy_device * ethnl_req_get_phydev (const struct ethnl_req_info
*req_info , struct nlattr **tb , unsigned int header , struct
netlink_ext_ack *extack );

πŸŽ€ ARGUMENTS πŸŽ€

  • req_info β€” the ethnl request you're pulling the phy from 🫢
  • tb β€” the netlink attributes array, and it's here purely for error reporting πŸ“‹
  • header β€” the netlink header index, also used for error reporting πŸ”
  • extack β€” the netlink extended ACK, again for error reporting πŸ’¬

πŸ’– DESCRIPTION πŸ’–

so here's the vibe: if a phy_device is returned, the caller must hold rtnl_lock when calling this function β€” and must keep holding it until it's fully done interacting with the returned phy_device. πŸ”’ IOW, caller must hold rtnl_lock unless they know the netdev has no phy_device. no cap, this is the rule πŸ’…

⚠️ fr fr, do not skip the lock thing. it's giving "hold rtnl_lock" for a reason 😭

🌈 RETURN 🌈

you get a phy_device pointer that corresponds either to the passed phy_index, if one is provided. if not? you get the phy_device attached to the net_device targeted by this request. 🎯

  • if there's no targeted net_device, or no phy_device is attached β†’ NULL comes back πŸ™ˆ
  • if the provided phy_index is invalid β†’ an error pointer comes back πŸ’€

πŸ¦‹ SEE ALSO πŸ¦‹

Kernel file ./net/ethtool/netlink.h, plus all these iconic siblings ✨:


and that's the whole page, bestie πŸ’œ this one lives in ./net/ethtool, dated October 2026, and it's lowkey the ethnl_req_get_phydev(9) moment of all time πŸ‘‘ signed off with a πŸ“ and a 🧚 β€” go hold that lock ✨

πŸ“¦ where this page comes from