STRUCT IWL_MAC_CFG(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

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

okay so bestie, we're in the Kernel API Manual section of the man pages and the star of this episode is struct iwl_mac_cfg β€” it's literally the info about the MAC-specific device part, and it's giving very much "backstage pass to the hardware" energy πŸŽ€


✨ SYNOPSIS ✨

struct iwl_mac_cfg {
    const struct iwl_family_base_params *base;
    enum iwl_device_family device_family;
    u32 umac_prph_offset;
    u32 xtal_latency;
    u32 extra_phy_cfg_flags;
    u32 gen2:1, mq_rx_supported:1, integrated:1, low_latency_xtal:1,
bisr_workaround:1, ltr_delay:2, imr_enabled:1;
 };

like, yes, that indentation on the bitfield line is a little feral but we do NOT touch it, we respect the original πŸ’…


πŸ¦‹ Members πŸ¦‹

  • base β€” a pointer to the basic parameters. the foundation, the main character of pointers fr fr.
  • device_family β€” the device family. which squad this hardware rolls with.
  • umac_prph_offset β€” the offset you add to the UMAC periphery address. it's a little math, no cap.
  • xtal_latency β€” power up latency to get the xtal stabilized. we wait, we're patient, we let the crystal cook ✨
  • extra_phy_cfg_flags β€” extra configuration flags to pass to the PHY. lil bonus flags, a gift 🎁
  • gen2 β€” 22000 and on transport operation.
  • mq_rx_supported β€” multi-queue rx support. queues upon queues, we love to see it πŸ”₯
  • integrated β€” discrete or integrated.
  • low_latency_xtal β€” use the low latency xtal if supported. only if it's supported bestie, don't get ahead of yourself.
  • bisr_workaround β€” BISR hardware workaround (for 22260 series devices). very specific, very niche, very iconic πŸ‘‘
  • ltr_delay β€” LTR delay parameter, enum iwl_mac_cfg_ltr_delay. (it's a 2-bit field btw, iykyk)
  • imr_enabled β€” use the IMR if supported. again: if supported 🫢

πŸ’œ Description πŸ’œ

okay so the whole vibe here: these values are specific to the device ID, and they do not change when multiple configs are used for a single device ID. like, they're locked in, they're committed, they're not doing the on-again-off-again thing 🌸

and these values get used, among other things, to boot the NIC so that the HW REV or RFID can be read before deciding the remaining parameters to use. so it's a little "peek first, decide later" situation and honestly? smart. very main character energy of the NIC ngl 😭

heads up bestie: the original text really does say "They values are used" β€” we're not fixing the manpage's grammar, we're just here to relay the facts πŸ’€

🌈 SEE ALSO 🌈

  • Kernel file ./drivers/net/wireless/intel/iwlwifi/iwl-config.h
  • enum iwl_nvm_type(9)
  • struct iwl_fw_mon_reg(9)
  • struct iwl_fw_mon_regs(9)
  • struct iwl_family_base_params(9)
  • struct iwl_tt_params(9)
  • struct iwl_rf_cfg(9)

go read them, they're all part of the same friend group ✨


and that's the whole page, bestie 🫢 this one came from the kernel file ./drivers/net/wireless/intel/i... (yes it's truncated in the footer, we suffer together 😭) with an October 2026 date on it β€” she's fresh, she's documented, she's periodt. πŸ’…πŸŽ€

πŸ“¦ where this page comes from