STRUCT SCMI_XFER(9)

🦋 struct scmi_xfer 🦋

okay so bestie, welcome to the Kernel API Manual corner where we're decoding struct scmi_xfer, and it's literally giving "structure representing a message flow" energy. 💅✨

💖 NAME 💖

struct scmi_xfer — the structure representing a message flow. That's the whole vibe. 🎀

✨ SYNOPSIS ✨

       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);
         #define SCMI_XFER_IS_RAW(x)     ((x)->flags & SCMI_XFER_FLAG_IS_RAW);
         #define SCMI_XFER_FLAG_CHAN_SET BIT(1);
         #define SCMI_XFER_IS_CHAN_SET(x)                ((x)->flags &
       SCMI_XFER_FLAG_CHAN_SET);
           int flags;
           spinlock_t lock;
           void *priv;
        };

🌸 Members 🌸

• transfer_id — Unique ID for debug & profiling purpose. tracking icon behavior ✨
• 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. efficient queen behavior 🫶
• 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. no premature vanishing, periodt 💀✨
• 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.

🔮 SEE ALSO 🔮

Kernel file ./drivers/firmware/arm_scmi/protocols.h and these absolute icons:

• struct scmi_msg_resp_prot_version(9)
• struct scmi_msg(9)
• struct scmi_msg_hdr(9)
• struct scmi_protocol_handle(9)
• struct scmi_iterator_state(9)
• struct scmi_iterator_ops(9)
• struct scmi_proto_helpers_ops(9)
• struct scmi_xfer_ops(9)
• struct scmi_protocol(9)

💌 cute sign-off: source/version is ./drivers/firmware/arm_scmi, date is October 2026, and this page is struct scmi_xfer(9). byeee bestie 🫶🌈