scmi_xfer_lookup_unlocked(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… scmi_xfer_lookup_unlocked(9) β€” Kernel API Manual

okay bestie, welcome to the kernel API manual for scmi_xfer_lookup_unlocked(9), and yes you're gonna slay this one 🫢


✨ NAME ✨

scmi_xfer_lookup_unlocked β€” a little helper that looks up an xfer_id. that's it. that's the whole job. icon behavior honestly πŸ‘‘


🌸 SYNOPSIS 🌸

struct scmi_xfer * scmi_xfer_lookup_unlocked (struct scmi_xfers_info
*minfo , u16 xfer_id );

like, you hand it a message-management struct and an id, and it goes and finds your transfer. main character function fr fr ⭐


πŸŽ€ ARGUMENTS πŸŽ€

  • minfo β€” pointer to the Tx/Rx Message management info, based on channel type. it's giving "which channel are we even on" energy, iykyk πŸ’«
  • xfer_id β€” the Token ID you wanna look up in pending_xfers. that's the thing it's searching for, no cap πŸ”

πŸ¦‹ DESCRIPTION πŸ¦‹

Refcounting is untouched. πŸ’€

like, it does not touch the refcount, bestie. not even a little. it just looks the thing up and minds its business. we love a function that stays in its lane 🌈


πŸ’œ CONTEXT πŸ’œ

assumes it's being called with xfer_lock already acquired πŸ”’

so like, lock first, then call. that's the vibe check and you must pass it, okay? 🫢


πŸ”₯ RETURN πŸ”₯

a valid xfer on success, or an error otherwise. that's the whole deal β€” you either get your transfer or you get told no πŸ™ˆ


πŸ‘‘ SEE ALSO πŸ‘‘

go check out the kernel file ./drivers/firmware/arm_scmi/driver.c β€” it's the mothership, and these are all its friends:

that's a lot of reading, but you're built different, so πŸ’…


🌸 that's the whole page, bestie β€” this one came from ./drivers/firmware/arm_scmi, dated October 2026, and it's literally called scmi_xfer_lookup_unlocked(9) in case you forgot already 😭 go forth and look up those xfers, mwah πŸŽ€

πŸ“¦ where this page comes from