drivers/firmware/arm_scmi/protocols.h
Source file repositories/reference/linux-study-clean/drivers/firmware/arm_scmi/protocols.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/firmware/arm_scmi/protocols.h- Extension
.h- Size
- 15362 bytes
- Lines
- 396
- Domain
- Driver Families
- Bucket
- drivers/firmware
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/bitfield.hlinux/completion.hlinux/device.hlinux/errno.hlinux/kernel.hlinux/hashtable.hlinux/list.hlinux/module.hlinux/refcount.hlinux/scmi_protocol.hlinux/spinlock.hlinux/types.hlinux/unaligned.h
Detected Declarations
struct scmi_msg_resp_prot_versionstruct scmi_msgstruct scmi_msg_hdrstruct scmi_xferstruct scmi_xfer_opsstruct scmi_proto_helpers_opsstruct scmi_protocol_handlestruct scmi_iterator_statestruct scmi_iterator_opsstruct scmi_fc_db_infostruct scmi_fc_infostruct scmi_proto_helpers_opsstruct scmi_xfer_opsstruct scmi_protocolenum scmi_common_cmd
Annotated Snippet
struct scmi_msg_resp_prot_version {
__le16 minor_version;
__le16 major_version;
};
/**
* struct scmi_msg - Message(Tx/Rx) structure
*
* @buf: Buffer pointer
* @len: Length of data in the Buffer
*/
struct scmi_msg {
void *buf;
size_t len;
};
/**
* struct scmi_msg_hdr - Message(Tx/Rx) header
*
* @id: The identifier of the message being sent
* @protocol_id: The identifier of the protocol used to send @id message
* @type: The SCMI type for this message
* @seq: The token to identify the message. When a message returns, the
* platform returns the whole message header unmodified including the
* token
* @status: Status of the transfer once it's complete
* @poll_completion: Indicate if the transfer needs to be polled for
* completion or interrupt mode is used
*/
struct scmi_msg_hdr {
u8 id;
u8 protocol_id;
u8 type;
u16 seq;
u32 status;
bool poll_completion;
};
/**
* struct scmi_xfer - Structure representing a message flow
*
* @transfer_id: Unique ID for debug & profiling purpose
* @hdr: Transmit message header
* @tx: Transmit message
* @rx: Receive message, the buffer should be pre-allocated to store
* message. If request-ACK protocol is used, we can reuse the same
* buffer for the rx path as we use for the tx path.
* @done: command message transmit completion event
* @async_done: pointer to delayed response message received event completion
* @pending: True for xfers added to @pending_xfers hashtable
* @node: An hlist_node reference used to store this xfer, alternatively, on
* the free list @free_xfers or in the @pending_xfers hashtable
* @users: A refcount to track the active users for this xfer.
* This is meant to protect against the possibility that, when a command
* transaction times out concurrently with the reception of a valid
* response message, the xfer could be finally put on the TX path, and
* so vanish, while on the RX path scmi_rx_callback() is still
* processing it: in such a case this refcounting will ensure that, even
* though the timed-out transaction will anyway cause the command
* request to be reported as failed by time-out, the underlying xfer
* cannot be discarded and possibly reused until the last one user on
* the RX path has released it.
* @busy: An atomic flag to ensure exclusive write access to this xfer
* @state: The current state of this transfer, with states transitions deemed
* valid being:
* - SCMI_XFER_SENT_OK -> SCMI_XFER_RESP_OK [ -> SCMI_XFER_DRESP_OK ]
* - SCMI_XFER_SENT_OK -> SCMI_XFER_DRESP_OK
* (Missing synchronous response is assumed OK and ignored)
* @flags: Optional flags associated to this xfer.
* @lock: A spinlock to protect state and busy fields.
* @priv: A pointer for transport private usage.
*/
struct scmi_xfer {
int transfer_id;
struct scmi_msg_hdr hdr;
struct scmi_msg tx;
struct scmi_msg rx;
struct completion done;
struct completion *async_done;
bool pending;
struct hlist_node node;
refcount_t users;
#define SCMI_XFER_FREE 0
#define SCMI_XFER_BUSY 1
atomic_t busy;
#define SCMI_XFER_SENT_OK 0
#define SCMI_XFER_RESP_OK 1
#define SCMI_XFER_DRESP_OK 2
int state;
#define SCMI_XFER_FLAG_IS_RAW BIT(0)
Annotation
- Immediate include surface: `linux/bitfield.h`, `linux/completion.h`, `linux/device.h`, `linux/errno.h`, `linux/kernel.h`, `linux/hashtable.h`, `linux/list.h`, `linux/module.h`.
- Detected declarations: `struct scmi_msg_resp_prot_version`, `struct scmi_msg`, `struct scmi_msg_hdr`, `struct scmi_xfer`, `struct scmi_xfer_ops`, `struct scmi_proto_helpers_ops`, `struct scmi_protocol_handle`, `struct scmi_iterator_state`, `struct scmi_iterator_ops`, `struct scmi_fc_db_info`.
- Atlas domain: Driver Families / drivers/firmware.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.