STRUCT HTT_Q_STATE(9)

💖 NAME 💖

ok so struct htt_q_state — it's the struct that's literally shared between host and firmware via DMA 🫶 like they're passing notes in class but make it hardware.

---

✨ SYNOPSIS ✨

struct htt_q_state {
    u8 count[HTT_TX_Q_STATE_NUM_TIDS][HTT_TX_Q_STATE_NUM_PEERS];
    u32 map[HTT_TX_Q_STATE_NUM_TIDS][(HTT_TX_Q_STATE_NUM_PEERS + 31) /
32];
    __le32 seq;
 };

lowkey the formatting of that map line is doing its own thing but we respect it 💅

---

🌸 Members 🌸

• count — every single element here is the host queue depth, no cap. when the q depth type got configured as HTT_Q_DEPTH_TYPE_BYTES, each entry is defined as: FACTOR * 128 * 8^EXP (peep HTT_TX_Q_STATE_ENTRY_FACTOR_MASK and HTT_TX_Q_STATE_ENTRY_EXP_MASK if you wanna see the masks 👀). and when the q depth type got configured as HTT_Q_DEPTH_TYPE_MSDUS, the number of packets gets scaled by 2 ** record_multiplier (check htt_q_state_conf for that one, bestie).
• map — firmware's lil shortcut for quickly checking which host queues are not empty. it's a bitmap, simply saying. 🗺️✨
• seq — firmware uses this to quickly check whether the host queues were updated since the last time it looked. it's giving "did u text me back" energy fr fr 💀

---

🦋 Description 🦋

so this structure is how the host exposes its software queue state to the firmware — main character energy 👑 — so that the firmware's rate control can schedule fetch requests for optimized performance. it's most notably used for MU-MIMO aggregation when multiple MU clients are connected 🎀

FIXME: is the q_state map[] size calculation really correct? 😭 genuinely asking, whoever wrote this left us on read

---

🌈 SEE ALSO 🌈

• Kernel file ./drivers/net/wireless/ath/ath10k/htt.h struct htt_q_state_conf(9)

---

ok that's the whole page, go slay ur queue state bestie 💜🌸

sign-off time 🫶 this one's from the Kernel API Manual, living under ./drivers/net/wireless/ath/ath10k, dated October 2026 — struct htt_q_state(9), periodt. ✨