pcs_inband_caps(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… pcs_inband_caps β€” the kernel API manual, bestie edition

okay so this page is pcs_inband_caps(9) and it's literally all about asking your PCS what in-band stuff it can do for a given interface mode. short page, but iconic. let's get into it 🫢


✨ NAME ✨

pcs_inband_caps β€” query PCS in-band capabilities for interface mode.

like, "hey bestie, what in-band signalling are you actually about?" that kind of vibe check, but for a PCS. πŸ’…


🌸 SYNOPSIS 🌸

unsigned int pcs_inband_caps (struct phylink_pcs *pcs , phy_interface_t
interface );

yes the line break is real, no we are not fixing it, it's part of the aesthetic now πŸŽ€


πŸ¦‹ ARGUMENTS πŸ¦‹

  • pcs β€” a pointer to a struct phylink_pcs. that's the main character here, the PCS you're questioning.
  • interface β€” the interface mode to be queried. this is the "for which mode though?" part, because capabilities are per-interface-mode bestie, not one-size-fits-all ✨

πŸ’– DESCRIPTION πŸ’–

so here's the tea: this returns zero if it is unknown what in-band signalling is supported by the PHY β€” for example because the PHY driver doesn't implement the method. not a flex, just a "we genuinely don't know" signal, no cap. 😭

otherwise? it returns a bit mask of the LINK_INBAND_* values from enum link_inband_signalling to describe which inband modes are supported for this interface mode. so like, each bit is a little flag saying "yep, we do this one". very demure, very bitmask. πŸ‘‘


πŸ”₯ SEE ALSO πŸ”₯

like i said, whole friend group. go say hi to all of them πŸ§šπŸ’œ


and that's the whole page bestie, no notes. this one's coming at you from ./include/linux and it's dated October 2026, filed under pcs_inband_caps(9). slay, go query some capabilities πŸ’…βœ¨πŸŒˆ

πŸ“¦ where this page comes from