ENUM IEEE802154_HW_FLAGS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ‘‘ enum ieee802154_hw_flags(9) β€” the Kernel API Manual, bestie edition

okay so this is a page from the Kernel API Manual about enum ieee802154_hw_flags, and honestly? it's giving "tiny enum, big responsibilities." let's get into it πŸ’…


✨ NAME ✨

enum ieee802154_hw_flags β€” hardware flags, periodt. that's it, that's the name.


πŸ¦‹ SYNOPSIS πŸ¦‹

here's the whole enum, exactly as it lives, no cap:

enum ieee802154_hw_flags {
    IEEE802154_HW_TX_OMIT_CKSUM ,
    IEEE802154_HW_LBT ,
    IEEE802154_HW_CSMA_PARAMS ,
    IEEE802154_HW_FRAME_RETRIES ,
    IEEE802154_HW_AFILT ,
    IEEE802154_HW_PROMISCUOUS ,
    IEEE802154_HW_RX_OMIT_CKSUM

};

seven flags. that's the whole squad. 🌈


πŸŽ€ Constants πŸŽ€

okay, one by one, because each of these lil guys is a hardware capability check:

  • IEEE802154_HW_TX_OMIT_CKSUM β€” means the transmitter adds the FCS all on its own. the manpage literally says "Indicates that xmitter will add FCS on it's own." β€” yes, "xmitter," yes, "it's," we're keeping it, it's iconic πŸ’€ your driver doesn't have to do the checksum math.
  • IEEE802154_HW_LBT β€” means the transceiver supports listen before transmit. like it peeks before it speaks, very polite, very mindful 🫢
  • IEEE802154_HW_CSMA_PARAMS β€” means the transceiver supports csma parameters (max_be, min_be, backoff exponents). the backoff lore goes deep, iykyk.
  • IEEE802154_HW_FRAME_RETRIES β€” means the transceiver supports ARET frame retries setting. yes, ARET, capital letters, it's a whole thing ✨
  • IEEE802154_HW_AFILT β€” means the transceiver supports hardware address filter setting. filtering addresses in hardware like a main character πŸ‘‘
  • IEEE802154_HW_PROMISCUOUS β€” means the transceiver supports promiscuous mode setting. it hears everything. gossip mode unlocked πŸ™ˆ
  • IEEE802154_HW_RX_OMIT_CKSUM β€” means the receiver omits FCS. no FCS on the way in, that's the vibe πŸ¦‹

πŸ’– Description πŸ’–

so what are these flags even for? they're how the hardware tells the stack what it can and can't do β€” capability receipts, basically πŸ’…

the general design principle: flags here should be defined in a way that the simplest hardware doesn't need to set any particular flag at all. like, the bare-minimum chip should be able to just... exist. no flags, no drama. the absence of a flag is the default story.

but bestie, there ARE exceptions to this rule. so the manpage says you are advised to review these flags carefully. don't just assume the default β€” go read them. πŸ”₯

🌸 SEE ALSO 🌸

go read these next, they're all in the same orbit:


and that's the page!! mwah πŸ’‹ this lil number lives in ./include/net and it's dated October 2026, so yeah, it's from the future, we don't question it. stay slay, go set your flags correctly, and remember: the simplest hardware sets nothing at all. πŸ§šπŸ’œ

πŸ“¦ where this page comes from