STRUCT SCMI_DESC(9)

okay so bestie, this is the struct scmi_desc(9) page from the Kernel API Manual ✨ — it's the description of SoC integration, and it's lowkey the blueprint for how a transport gets set up, no cap 💅.

✨ NAME ✨

struct scmi_desc - Description of SoC integration. That's the whole vibe: it's the struct that describes the SoC integration for SCMI 🫶.

🌸 SYNOPSIS 🌸

struct scmi_desc {
    const struct scmi_transport_ops *ops;
    int max_rx_timeout_ms;
    int max_msg;
    int max_msg_size;
    unsigned int atomic_threshold;
    bool no_completion_irq;
    const bool force_polling;
    const bool sync_cmds_completed_on_ret;
    const bool atomic_enabled;
};

🎀 Members 🎀

• ops — pointer to the transport-specific ops structure. It's giving "here's how this transport does its thing" 💖.
• max_rx_timeout_ms — timeout for communication with SoC (in Milliseconds). Yes, milliseconds, so don't get it twisted ⏱️.
• max_msg — maximum number of messages for a channel type (tx or rx) that can be pending simultaneously in the system. May be overridden by the get_max_msg op, iykyk 😌.
• max_msg_size — maximum size of data payload per message that can be handled 🎁.
• atomic_threshold — optional system wide DT-configured threshold, expressed in microseconds, for atomic operations. Only SCMI synchronous commands reported by the platform to have an execution latency lesser-equal to the threshold should be considered for atomic mode operation: such decision is finally left up to the SCMI drivers. Literally the platform says "this one's fast enough," and the SCMI drivers make the final call 💅.
• no_completion_irq — flag to indicate that this transport has no completion interrupt and has to be polled. This is similar to the force_polling below, except this is set via DT property. So: no irq, just polling 🌀.
• force_polling — flag to force this whole transport to use SCMI core polling mechanism instead of completion interrupts even if available. Periodt, polling over interrupts 🔥.
• sync_cmds_completed_on_ret — flag to indicate that the transport assures synchronous-command messages are atomically completed on .send_message: no need to poll actively waiting for a response. Used by core internally only when polling is selected as a waiting for reply method: i.e. if a completion irq was found use that anyway. The way that .send_message just finishes the sync command atomically is iconic 🎀.
• atomic_enabled — flag to indicate that this transport, which is assured not to sleep anywhere on the TX path, can be used in atomic mode when requested. No sleeping on the TX path, bestie — atomic mode gets the green light when asked ⚡.

🌈 SEE ALSO 🌈

• Kernel file ./drivers/firmware/arm_scmi/common.h
• pack_scmi_header(9)
• unpack_scmi_header(9)
• struct scmi_chan_info(9)
• struct scmi_transport_ops(9)
• struct scmi_debug_info(9)
• struct scmi_shmem_io_ops(9)
• struct scmi_shared_mem_operations(9)
• struct scmi_message_operations(9)
• struct scmi_transport_core_operations(9)
• struct scmi_transport_handle(9)
• struct scmi_transport(9)
• struct scmi_transport_supplier(9)
• scmi_transport_supplier_put(9)
• scmi_transport_supplier_get(9)

mwah 💋 — this page's source/version is ./drivers/firmware/arm_scmi, dated October 2026, and the footer tag is struct scmi_desc(9). slay and read your kernel docs 🦋.