ti_sci_cmd_...ce_exclusive(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… NAME πŸ’…

ti_sci_cmd_get_device_exclusive β€” the command where you ask for a device managed by TISCI that your host gets to own exclusively, no sharing, no crumbs πŸ’–

Quick lil housekeeping bestie: this page lives in the Kernel API Manual, and its header goes by ti_sci_cmd_...ce_exclusive(9) β€” yeah the title's truncated, don't @ me, that's just how it printed 😭


✨ SYNOPSIS ✨

int ti_sci_cmd_get_device_exclusive (const struct ti_sci_handle *handle
, u32 id );

πŸŽ€ ARGUMENTS πŸŽ€

  • handle β€” your pointer to the TISCI handle, which you get from *ti_sci_get_handle 🫢 like your lil VIP pass to the whole thing
  • id β€” the Device Identifier, aka which device you're claiming πŸ‘‘

🌸 DESCRIPTION 🌸

Okay so this is the "request for the device" call. You're asking for it, officially, on the record πŸ’…

⚠️ NOTE, and this one is loud: the client MUST maintain integrity of usage count by balancing get_device with put_device. No refcounting is managed by the driver for that purpose. So no cap, if you get_device and then ghost the put_device, that's on you, not the driver πŸ™ˆ

πŸ¦‹ RETURN πŸ¦‹

0 if all went fine ✨ β€” otherwise it returns the appropriate error, so like, vibe check your return value ngl πŸ’€


πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./drivers/firmware/ti_sci.c β€” and honestly the whole friend group showed up, so here's the full roster 🫢


And that's the whole page bestie, you ate that πŸ“ This one came from ./drivers/firmware, dated October 2026, and the page signs off as ti_sci_cmd_...ce_exclusive(9) β€” iconic, no notes πŸ’œβœ¨

πŸ“¦ where this page comes from