scmi_do_xfer_raw_start(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… scmi_do_xfer_raw_start(9) β€” from the Kernel API Manual, bestie

okay so picture this: you're deep in the arm_scmi firmware driver, you've already built yourself a shiny raw xfer, and now you just need someone to actually send it. that's this function. it's the little helper that does the sending. icon behavior only. ✨


🌸 NAME 🌸

scmi_do_xfer_raw_start β€” an helper to send a valid raw xfer 🫢


πŸŽ€ SYNOPSIS πŸŽ€

int scmi_do_xfer_raw_start (struct scmi_raw_mode_info *raw , struct
       scmi_xfer *xfer , u8 chan_id , bool async );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • raw β€” a reference to the Raw instance. like, the whole vibe. you gotta hand it over.
  • xfer β€” the xfer to send. the main character of this whole operation, fr fr.
  • chan_id β€” the channel ID to use. and here's the tea 🍡: if it's zero, the channel gets automatically selected based on the protocol used. so 0 = "you pick for me, i trust you."
  • async β€” a flag stating if an asynchronous command is required. bool. yes or no. that's it. that's the whole flag.

πŸ’– DESCRIPTION πŸ’–

This function sends a previously built raw xfer using an appropriate channel, and then queues the related waiting work. so basically: send it, and don't forget to set up the follow-up. πŸ’…

and now the important part, no cap: we need to know explicitly whether the required command is meant to be asynchronous in kind, because we have to properly set up the waiter. you can't just vibe-check it from the payload β€” deducing it that way is weak and does not scale, given there is NOT a common header-flag stating if the command is asynchronous or not. 😭 so pass the flag. be honest with the function. it's a whole trust thing.


✨ RETURN ✨

0 on Success πŸ”₯


🌈 SEE ALSO 🌈


and that's the page, bestie 🧚 this little gem lives over in ./drivers/firmware/arm_scmi, dated October 2026, and it answers to the name scmi_do_xfer_raw_start(9). go forth and send those raw xfers πŸ’œ

πŸ“¦ where this page comes from