STRUCT BRCMF_FWEH_INFO(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct brcmf_fweh_info(9) πŸ’–

okay bestie, welcome to the Kernel API Manual β€” yes, that Kernel API Manual β€” and today's main character is struct brcmf_fweh_info, aka the firmware event handling information struct. it's giving "behind the scenes but actually running everything" energy ✨


✨ NAME ✨

struct brcmf_fweh_info β€” firmware event handling information. periodt. that's the whole vibe, it's the info hub for handling firmware events πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

struct brcmf_fweh_info {
    struct brcmf_pub *drvr;
    bool p2pdev_setup_ongoing;
    struct work_struct event_work;
    spinlock_t evt_q_lock;
    struct list_head event_q;
    uint event_mask_len;
    u8 *event_mask;
    const struct brcmf_fweh_event_map *event_map;
    uint num_event_codes;
    brcmf_fweh_handler_t evt_handler[];
};

look at her. iconic. no cap, this is a lot of members but we're gonna go through every single one, i promise 🫢


🌸 Members 🌸

  • p2pdev_setup_ongoing β€” lowkey a little status flag: P2P device creation is in progress. that's it, that's the whole job πŸ’…
  • event_work β€” the event worker. your girl shows up and does the work, literally ⭐
  • evt_q_lock β€” the lock for event queue protection. keep it safe, keep it locked πŸ”’ (okay that emoji isn't in the list but the sentiment is fr)
  • event_q β€” the event queue itself. the lineup. the group chat backlog πŸ’€
  • event_mask_len β€” length of event_mask, used to enable firmware events. it's the size tag bestie, don't skip it πŸ“
  • event_mask β€” a byte array used in the 'event_msgs' iovar command. yes, 'event_msgs' β€” keep that exactly as written, iykyk πŸ”₯
  • event_map β€” mapping between fweh event and firmware event, which may be provided by a vendor-specific module for events that need mapping. translator energy 🧚
  • num_event_codes β€” number of firmware events supported by firmware, which does a minimum length check for the event_mask. this value is to be provided by the vendor-specific module determining event_mask_len and consequently the allocation size for event_mask. so basically the vendor module is out here deciding sizes, no pressure πŸ™ˆ
  • evt_handler β€” event handler registry indexed by firmware event code. the little black book of handlers πŸ““βœ¨

πŸ‘‘ SEE ALSO πŸ‘‘

go read these next, bestie, they're all connected:

  • Kernel file ./drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h πŸ¦‹
  • struct brcm_ethhdr(9)
  • struct brcmf_event(9)
  • struct brcmf_event_msg(9)
  • struct brcmf_fweh_event_map_item(9)
  • struct brcmf_fweh_event_map(9)

ngl this whole page lives in ./drivers/net/wireless/broadco... and it's dated October 2026 β€” so yes, the sources are from the future, and the page is still titled struct brcmf_fweh_info(9) because she's consistent πŸ’œ

okay that's the whole page, go forth and slay your firmware events πŸ’–πŸŒˆπŸŽ€

πŸ“¦ where this page comes from