ath5k_hw_get_txdp(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– ath5k_hw_get_txdp(9) πŸ’–

okay so real talk, this is a page straight out of the Kernel API Manual, and it's all about grabbing the TX descriptor address for a specific queue. bestie, it's giving "one tiny function, huge main character energy" ✨


🌸 NAME 🌸

ath5k_hw_get_txdp β€” get the TX Descriptor's address for a specific queue πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

u32 ath5k_hw_get_txdp (struct ath5k_hw *ah , unsigned int queue );

πŸ’… ARGUMENTS πŸ’…

  • ah β€” the struct ath5k_hw, literally the whole hardware vibe 🫢
  • queue β€” the hw queue number, iykyk πŸ”₯

✨ DESCRIPTION ✨

So what does it do? It gets the TX descriptor's address for a specific queue, periodt. πŸ’…

For 5210 we straight up ignore the queue number and use the tx queue type instead, because we only have 2 queues β€” that's the whole situation, no cap. We use TXDP0 for the normal data queue and TXDP1 for the beacon queue πŸŽ€. For newer chips with QCU/DCU we just read the corresponding TXDP register. slay. ✨

XXX: Is TXDP read and clear ? πŸ‘€ (yes bestie, the original page really does leave that question hanging, and we're not about to invent an answer πŸ™ˆ)

🌈 SEE ALSO 🌈

Kernel file ./drivers/net/wireless/ath/ath5k/dma.c DMA and interrupt masking functions(9) β€” plus the whole friend group:


and that's the whole page, bestie 🫢 this little icon lives at ./drivers/net/wireless/ath/ath5k, dated October 2026, and the page itself is ath5k_hw_get_txdp(9) β€” go read it again whenever you need the vibe check πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from