scmi_xfer_raw_get_init(9)

📦 version 7.3.1, in nixpkgs unstable

✨ scmi_xfer_raw_get_init(9) ✨

okay so bestie, we're in the Kernel API Manual today and this little icon is literally the glow-up assistant for raw SCMI messages 💅 like, it takes your bare message and turns it into a valid xfer. main character energy fr fr.

🌸 SYNOPSIS 🌸

int scmi_xfer_raw_get_init(struct scmi_raw_mode_info *raw, void *buf,
                           size_t len, struct scmi_xfer **p);

🎀 ARGUMENTS 🎀

  • raw — a reference to the Raw instance. like, the whole raw-mode situation you're working with 🫶
  • buf — a buffer holding the entire SCMI message you wanna send, header and all, in little-endian binary formmat (yes that's literally how it's spelled in the source, don't come for me 😭💀)
  • len — how long the message in buf is, in bytes 📏
  • p — a pointer where the freshly initialized Raw xfer gets handed back to you ✨

🦋 DESCRIPTION 🦋

so here's the vibe: an xfer gets picked out of the TX pool, the message content gets poured into it, and then it's registered as pending with the core the usual way — using the original sequence number the user supplied along with the message. no cap, that's the whole flow 👑

⚠️ ok but listen — if your testing user application is NOT using distinct sequence numbers between successive SCMI messages, that registration could fail temporarily if the previous message (the one with the same sequence number) hadn't been released yet. and in that case? we literally just wait and retry. patient queen behavior 🙈⏳

💖 RETURN 💖

0 on Success. slay. 🎉

⭐ SEE ALSO ⭐

and that's the whole page bestie, iykyk 🧚‍♀️💜 this one lives over in ./drivers/firmware/arm_scmi, stamped October 2026 — go off, kernel docs, periodt 🎀🔥

📦 where this page comes from