drivers/net/wireless/intel/iwlwifi/fw/api/cmdhdr.h
Source file repositories/reference/linux-study-clean/drivers/net/wireless/intel/iwlwifi/fw/api/cmdhdr.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/wireless/intel/iwlwifi/fw/api/cmdhdr.h- Extension
.h- Size
- 4467 bytes
- Lines
- 157
- 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
- No C-style include directives detected by the generator.
Detected Declarations
struct iwl_cmd_headerstruct iwl_cmd_header_widestruct iwl_calib_res_notif_phy_dbstruct iwl_phy_db_cmdstruct iwl_cmd_responsefunction Copyrightfunction iwl_cmd_groupidfunction iwl_cmd_versionfunction iwl_cmd_id
Annotated Snippet
struct iwl_cmd_header {
/**
* @cmd: Command ID: REPLY_RXON, etc.
*/
u8 cmd;
/**
* @group_id: group ID, for commands with groups
*/
u8 group_id;
/**
* @sequence:
* Sequence number for the command.
*
* The driver sets up the sequence number to values of its choosing.
* uCode does not use this value, but passes it back to the driver
* when sending the response to each driver-originated command, so
* the driver can match the response to the command. Since the values
* don't get used by uCode, the driver may set up an arbitrary format.
*
* There is one exception: uCode sets bit 15 when it originates
* the response/notification, i.e. when the response/notification
* is not a direct response to a command sent by the driver. For
* example, uCode issues REPLY_RX when it sends a received frame
* to the driver; it is not a direct response to any driver command.
*
* The Linux driver uses the following format:
*
* 0:7 tfd index - position within TX queue
* 8:12 TX queue id
* 13:14 reserved
* 15 unsolicited RX or uCode-originated notification
*/
__le16 sequence;
} __packed;
/**
* struct iwl_cmd_header_wide - wide command header
*
* This header format appears in the beginning of each command sent from the
* driver, and each response/notification received from uCode.
* this is the wide version that contains more information about the command
* like length, version and command type
*
* @cmd: command ID, like in &struct iwl_cmd_header
* @group_id: group ID, like in &struct iwl_cmd_header
* @sequence: sequence, like in &struct iwl_cmd_header
* @length: length of the command
* @reserved: reserved
* @version: command version
*/
struct iwl_cmd_header_wide {
u8 cmd;
u8 group_id;
__le16 sequence;
__le16 length;
u8 reserved;
u8 version;
} __packed;
/**
* struct iwl_calib_res_notif_phy_db - Receive phy db chunk after calibrations
* @type: type of the result - mostly ignored
* @length: length of the data
* @data: data, length in @length
*/
struct iwl_calib_res_notif_phy_db {
__le16 type;
__le16 length;
u8 data[];
} __packed;
/**
* struct iwl_phy_db_cmd - configure operational ucode
* @type: type of the data
* @length: length of the data
* @data: data, length in @length
*/
struct iwl_phy_db_cmd {
__le16 type;
__le16 length;
u8 data[];
} __packed;
/**
* struct iwl_cmd_response - generic response struct for most commands
* @status: status of the command asked, changes for each one
*/
struct iwl_cmd_response {
__le32 status;
};
Annotation
- Detected declarations: `struct iwl_cmd_header`, `struct iwl_cmd_header_wide`, `struct iwl_calib_res_notif_phy_db`, `struct iwl_phy_db_cmd`, `struct iwl_cmd_response`, `function Copyright`, `function iwl_cmd_groupid`, `function iwl_cmd_version`, `function iwl_cmd_id`.
- 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.