STRUCT SCMI_TRANSPORT_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct scmi_transport_ops(9) β€” like, the entire mood board for an SCMI transport

okay so bestie, welcome to the Kernel API Manual, and today's main character is struct scmi_transport_ops β€” literally the structure that represents a SCMI transport ops. that's it, that's the vibe. it's the little bundle of function pointers that tells the rest of the world how your transport does its thing. no cap. ✨


✨ NAME ✨

struct scmi_transport_ops β€” structure representing a SCMI transport ops 🫢


🌸 SYNOPSIS 🌸

okay here's the whole glow-up, verbatim, do not touch:

struct scmi_transport_ops {
    bool (*chan_available)(struct device_node *of_node, int idx);
    int (*chan_setup)(struct scmi_chan_info *cinfo, struct device *dev,
bool tx);
    int (*chan_free)(int id, void *p, void *data);
    unsigned int (*get_max_msg)(struct scmi_chan_info *base_cinfo);
    int (*send_message)(struct scmi_chan_info *cinfo, struct scmi_xfer
*xfer);
    void (*mark_txdone)(struct scmi_chan_info *cinfo, int ret, struct
scmi_xfer *xfer);
    void (*fetch_response)(struct scmi_chan_info *cinfo, struct
scmi_xfer *xfer);
    void (*fetch_notification)(struct scmi_chan_info *cinfo, size_t
max_len, struct scmi_xfer *xfer);
    void (*clear_channel)(struct scmi_chan_info *cinfo);
    bool (*poll_done)(struct scmi_chan_info *cinfo, struct scmi_xfer
*xfer);
 };

like, look at all those callbacks. so many little jobs. each one a whole personality. πŸŽ€


πŸ‘‘ Members πŸ‘‘

πŸ’– the channel-management girlies

  • chan_available β€” callback to check if the channel is available or not. like a vibe check, but for channels. bestie, is the channel there or not, we need answers.
  • chan_setup β€” callback to allocate and setup a channel. it's giving "let me build you from scratch." πŸ› οΈ
  • chan_free β€” callback to free a channel. releasing it back into the wild. bye queen, you served. πŸ’…
  • get_max_msg β€” optional callback to provide max_msg dynamically. it returns the maximum number of messages for the channel type (tx or rx) that can be pending simultaneously in the system. yes, "optional" is doing heavy lifting there β€” don't come for me, that's the spec. ⭐

πŸ¦‹ the message-handling icons

  • send_message β€” callback to send a message. the actual "go, girl, go" of the whole operation. πŸ”₯
  • mark_txdone β€” callback to mark tx as done. closing the loop, stamping the receipt. βœ…
  • fetch_response β€” callback to fetch response. going to pick up what you ordered. 🌸
  • fetch_notification β€” callback to fetch notification. surprise delivery, but make it kernel. 🎁

🧚 the cleanup crew

  • clear_channel β€” callback to clear a channel. reset the group chat, start fresh. 🧹
  • poll_done β€” callback to poll transfer status. "are we there yet" in function pointer form. the way that it just keeps checking 😭

🌈 SEE ALSO 🌈

kernel file ./drivers/firmware/arm_scmi/common.h plus the whole friend group, all listed so you can go stan them too:

pack_scmi_header(9), unpack_scmi_header(9), struct scmi_chan_info(9), struct scmi_desc(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)

no cap, that's the whole list β€” every single one, bestie, I counted. πŸ’œ

and that's a wrap on struct scmi_transport_ops(9)! mwah πŸ’‹ this little page came straight out of ./drivers/firmware/arm_scmi, dated October 2026, and it's still filed under struct scmi_transport_ops(9) because some things never change, periodt. 🩷✨

πŸ“¦ where this page comes from