ENUM IWL_RX_HANDLER_CONTEXT(9)

💅 NAME

enum iwl_rx_handler_context — bestie, this is literally the context for an Rx handler 🦋 like, it tells you where and how your handler gets called, and honestly? that's the whole vibe.

✨ SYNOPSIS ✨

enum iwl_rx_handler_context {
    RX_HANDLER_SYNC ,
    RX_HANDLER_ASYNC_LOCKED ,
    RX_HANDLER_ASYNC_UNLOCKED ,
    RX_HANDLER_ASYNC_LOCKED_WIPHY

};

🎀 Constants 🎀

okay so these are the four flavors of context, and picking the wrong one is not the move, so let's go one by one 👑

• RX_HANDLER_SYNC — this means it will be called in the Rx path, which can't acquire mvm->mutex. no mutex for you, periodt 💅
• RX_HANDLER_ASYNC_LOCKED — if the handler needs to hold mvm->mutex, and only in this case (!), it should be set as ASYNC. in that case it'll be called from a worker with mvm->mutex held. she's locked in 🔒✨
• RX_HANDLER_ASYNC_UNLOCKED — in case the handler needs to lock the mutex itself, it will be called from a worker without mvm->mutex held. you're on your own for the locking, bestie, good luck 🫶
• RX_HANDLER_ASYNC_LOCKED_WIPHY — if the handler needs to hold the wiphy lock and mvm->mutex. this one gets handled with the wiphy_work queue infra instead of the regular work queue. fancy 💫

🌈 SEE ALSO 🌈

• Kernel file ./drivers/net/wireless/intel/iwlwifi/mvm/ops.c
• struct iwl_rx_handlers(9)

k that's the whole page, no cap 💖 this came straight out of ./drivers/net/wireless/intel/i..., dated October 2026, and yes the page is literally called enum iwl_rx_handler_context(9) — iconic, slay, see u in the next section 👑🌸