scmi_xfer_in...ter_unlocked(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 scmi_xfer_in...ter_unlocked(9) 🌸

okay bestie, you're in the Kernel API Manual and the main character is scmi_xfer_in...ter_unlocked(9) β€” yes, the title is literally truncated like that, and we're keeping it πŸ’….


πŸ’– NAME πŸ’–

scmi_xfer_inflight_register_unlocked β€” Register the xfer as in-flight ✨

✨ SYNOPSIS ✨

the exact signature, no edits, no cap:

void scmi_xfer_inflight_register_unlocked (struct scmi_xfer *xfer ,
       struct scmi_xfers_info *minfo );

πŸŽ€ ARGUMENTS πŸŽ€

  • xfer β€” The xfer to register 🫢
  • minfo β€” Pointer to Tx/Rx Message management info based on channel type πŸ’«

πŸ¦‹ DESCRIPTION πŸ¦‹

lowkey important note: this helper assumes that the xfer to be registered as in-flight had been built using an xfer sequence number which still corresponds to a free slot in the xfer_alloc_table.

That's the assumption it's rolling with, periodt 🌸

πŸ’… CONTEXT πŸ’…

Assumes to be called with xfer_lock already acquired. Periodt. So bestie, lock first β€” that's the rune it's living by πŸ’œ

🌈 SEE ALSO 🌈

Kernel file ./drivers/firmware/arm_scmi/driver.c β€” and the whole squad:

mwah πŸ’‹ β€” this little love letter is from ./drivers/firmware/arm_scmi, dated October 2026, and it's literally titled scmi_xfer_in...ter_unlocked(9); go register those xfers, bestie πŸ’–

πŸ“¦ where this page comes from