STRUCT SCM_LEGACY_COMMAND(9)

📦 version 7.3.1, in nixpkgs unstable

🎀 struct scm_legacy_command(9) 🎀

okay bestie, welcome to the Kernel API Manual 💖 this is the page for struct scm_legacy_command, and yes it's giving "one SCM command buffer" — that's the whole NAME vibe, we're keeping it ✨

🌸 SYNOPSIS 🌸

struct scm_legacy_command {
    __le32 len;
    __le32 buf_offset;
    __le32 resp_hdr_offset;
    __le32 id;
    __le32 buf[];
 };

no cap, that's the whole struct, and honestly it's lowkey gorgeous 💅

✨ Members ✨

  • len — the total available memory for the command and the response, together, one number, that's it 🫶
  • buf_offset — where the command buffer starts ✨
  • resp_hdr_offset — where the response buffer starts 🌸
  • id — the command that's actually gonna be executed, iykyk 👑
  • buf — the buffer you get back from scm_legacy_get_command_buffer 💖

🦋 Description 🦋

so the way an SCM command is laid out in memory is literally this, look 👀

 ------------------- <--- struct scm_legacy_command
 | command header  |
 ------------------- <--- scm_legacy_get_command_buffer
 | command buffer  |
 ------------------- <--- struct scm_legacy_response and
 | response header |      scm_legacy_command_to_response
 ------------------- <--- scm_legacy_get_response_buffer
 | response buffer |
 -------------------

iconic, right? but here's the part where you gotta listen to me 🥺 there can be arbitrary padding between the headers and the buffers. arbitrary!! so you should always use the appropriate scm_legacy_get_*_buffer routines to access the buffers in a safe manner. fr fr, do not go poking at offsets by hand, that's not the vibe 💀

🌈 SEE ALSO 🌈

go read them, they're all slay, I promise 🍓

mwah 💋 this came from ./drivers/firmware/qcom, dated October 2026 — that's the source and the date, wrapped up with a bow 🎀 go off and write some extremely safe buffer access okay?? 🧚‍♀️

📦 where this page comes from