drivers/net/wireless/intel/iwlwifi/fw/notif-wait.h
Source file repositories/reference/linux-study-clean/drivers/net/wireless/intel/iwlwifi/fw/notif-wait.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/wireless/intel/iwlwifi/fw/notif-wait.h- Extension
.h- Size
- 2956 bytes
- Lines
- 98
- Domain
- Driver Families
- Bucket
- drivers/net
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/wait.hiwl-trans.h
Detected Declarations
struct iwl_notif_wait_datastruct iwl_notification_waitfunction iwl_notification_notifyfunction iwl_notification_wait_notify
Annotated Snippet
struct iwl_notif_wait_data {
struct list_head notif_waits;
spinlock_t notif_wait_lock;
wait_queue_head_t notif_waitq;
};
#define MAX_NOTIF_CMDS 5
/**
* struct iwl_notification_wait - notification wait entry
* @list: list head for global list
* @fn: Function called with the notification. If the function
* returns true, the wait is over, if it returns false then
* the waiter stays blocked. If no function is given, any
* of the listed commands will unblock the waiter.
* @fn_data: pointer to pass to the @fn's data argument
* @cmds: command IDs
* @n_cmds: number of command IDs
* @triggered: waiter should be woken up
* @aborted: wait was aborted
*
* This structure is not used directly, to wait for a
* notification declare it on the stack, and call
* iwl_init_notification_wait() with appropriate
* parameters. Then do whatever will cause the ucode
* to notify the driver, and to wait for that then
* call iwl_wait_notification().
*
* Each notification is one-shot. If at some point we
* need to support multi-shot notifications (which
* can't be allocated on the stack) we need to modify
* the code for them.
*/
struct iwl_notification_wait {
struct list_head list;
bool (*fn)(struct iwl_notif_wait_data *notif_data,
struct iwl_rx_packet *pkt, void *data);
void *fn_data;
u16 cmds[MAX_NOTIF_CMDS];
u8 n_cmds;
bool triggered, aborted;
};
/* caller functions */
void iwl_notification_wait_init(struct iwl_notif_wait_data *notif_data);
bool iwl_notification_wait(struct iwl_notif_wait_data *notif_data,
struct iwl_rx_packet *pkt);
void iwl_abort_notification_waits(struct iwl_notif_wait_data *notif_data);
static inline void
iwl_notification_notify(struct iwl_notif_wait_data *notif_data)
{
wake_up_all(¬if_data->notif_waitq);
}
static inline void
iwl_notification_wait_notify(struct iwl_notif_wait_data *notif_data,
struct iwl_rx_packet *pkt)
{
if (iwl_notification_wait(notif_data, pkt))
iwl_notification_notify(notif_data);
}
/* user functions */
void __acquires(wait_entry)
iwl_init_notification_wait(struct iwl_notif_wait_data *notif_data,
struct iwl_notification_wait *wait_entry,
const u16 *cmds, int n_cmds,
bool (*fn)(struct iwl_notif_wait_data *notif_data,
struct iwl_rx_packet *pkt, void *data),
void *fn_data);
int __must_check __releases(wait_entry)
iwl_wait_notification(struct iwl_notif_wait_data *notif_data,
struct iwl_notification_wait *wait_entry,
unsigned long timeout);
void __releases(wait_entry)
iwl_remove_notification(struct iwl_notif_wait_data *notif_data,
struct iwl_notification_wait *wait_entry);
#endif /* __iwl_notif_wait_h__ */
Annotation
- Immediate include surface: `linux/wait.h`, `iwl-trans.h`.
- Detected declarations: `struct iwl_notif_wait_data`, `struct iwl_notification_wait`, `function iwl_notification_notify`, `function iwl_notification_wait_notify`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.