STRUCT SFP_MODULE_CAPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

struct sfp_module_caps β€” the vibe check for what an sfp module can actually do ✨

okay so this is from the Kernel API Manual, bestie, and it's literally just a little struct that holds all the "what can this module do tho" info 🫢


🌸 SYNOPSIS 🌸

struct sfp_module_caps {
    unsigned long interfaces[BITS_TO_LONGS(PHY_INTERFACE_MODE_MAX)];
    unsigned long link_modes[BITS_TO_LONGS(__ETHTOOL_LINK_MODE_MASK_NBITS)];
    bool may_have_phy;
    u8 port;
};

look at her. four members. immaculate. no notes πŸ’…


πŸŽ€ MEMBERS πŸŽ€

  • interfaces β€” a bitmap of the interfaces this module may support. may. as in, don't @ her, she's not promising anything πŸ’€
  • link_modes β€” a bitmap of the ethtool link modes the module may support. same energy, same "may" πŸ¦‹
  • may_have_phy β€” tells you whether the module might have an ethernet PHY. and ngl this one's a lil chaotic: there is no way to be sure a module has a PHY, because the EEPROM literally doesn't contain that information 😭 so when this is set, it does not mean the module definitely has a PHY. it means... maybe. iconically unhelpful but that's the truth πŸ™ˆ
  • port β€” one of the ethtool PORT_* definitions, parsed straight out of the module EEPROM πŸ‘‘ and if the port type isn't known? it's PORT_OTHER. mystery era πŸ’œ

πŸ¦‹ SEE ALSO πŸ¦‹

  • Kernel file ./include/linux/sfp.h
  • struct sfp_eeprom_id(9)
  • struct sfp_upstream_ops(9)

go read those next, they're lowkey connected iykyk ⭐


and that's the whole page, bestie β€” no cap 🌈 this one lives in ./include/linux and it's dated October 2026, so like... future queen behavior fr fr πŸ‘‘βœ¨ slay πŸ’–

πŸ“¦ where this page comes from