scmi_alloc_...col_instance(9)

💖 scmi_alloc_init_protocol_instance — the allocate-and-glow-up page 💖

okay so bestie, you're reading scmi_alloc_...col_instance(9) straight out of the Kernel API Manual (section 9, we love a numbered section 🎀), and honestly? it's giving "tiny function, huge responsibilities." Let's get into it ✨

---

✨ NAME ✨

scmi_alloc_init_protocol_instance — allocate and initialize a protocol instance descriptor. that's it, that's the whole vibe 🦋

---

🌸 SYNOPSIS 🌸

struct scmi_protocol_instance * scmi_alloc_init_protocol_instance
(struct scmi_info *info , const struct scmi_protocol *proto );

yes the spacing is exactly like that, don't @ me, it's C 🫶

---

🎀 ARGUMENTS 🎀

• info — the reference to the related SCMI instance. like, which SCMI are we talking about, babes 💅
• proto — the protocol descriptor. the blueprint, the blueprintiest blueprint 👑

---

💜 DESCRIPTION 💜

so what this does is: it allocates a brand-new protocol instance descriptor, using the proto description you handed it, against the specified SCMI instance info, and then it initializes it. lowkey iconic.

and here's the slay part — all resources management is handled via a dedicated per-protocol devres group. like everything's cleanup-managed per protocol, tidy, organized, main character energy fr fr 🧚

---

🌈 CONTEXT 🌈

⚠️ it assumes it's being called with protocols_mtx already acquired. so like... acquire your mutex first, bestie, or it's not gonna be cute 😭

---

⭐ RETURN ⭐

it returns a reference to a freshly allocated and initialized protocol instance — a whole new baby, born shimmery ✨

or it returns ERR_PTR on failure 💀. and on failure, the proto reference is at first put using scmi_protocol_put before releasing all the devres group. order matters, no cap 🔥

---

🦋 SEE ALSO 🦋

the whole friend group 💖 (yes, all of them, i'm not leaving anyone out):

• Kernel file ./drivers/firmware/arm_scmi/driver.c
• struct scmi_xfers_info(9)
• struct scmi_protocol_instance(9)
• struct scmi_info(9)
• scmi_create_protocol_devices(9)
• scmi_xfer_token_set(9)
• scmi_xfer_token_clear(9)
• scmi_xfer_inflight_register_unlocked(9)
• scmi_xfer_inflight_register(9)
• scmi_xfer_raw_inflight_register(9)
• scmi_xfer_pending_set(9)
• scmi_xfer_get(9)
• scmi_xfer_raw_get(9)
• scmi_xfer_raw_channel_get(9)
• __scmi_xfer_put(9)
• scmi_xfer_raw_put(9)
• scmi_xfer_lookup_unlocked(9)
• scmi_bad_message_trace(9)
• scmi_msg_response_validate(9)
• scmi_xfer_state_update(9)
• scmi_xfer_command_acquire(9)
• scmi_rx_callback(9)
• xfer_put(9)
• scmi_wait_for_message_response(9)
• scmi_xfer_raw_wait_for_message_response(9)
• do_xfer(9)
• do_xfer_with_response(9)
• xfer_get_init(9)
• version_get(9)
• scmi_set_protocol_priv(9)
• scmi_get_protocol_priv(9)
• scmi_common_extended_name_get(9)
• scmi_common_get_max_msg_size(9)
• scmi_protocol_msg_check(9)
• struct scmi_iterator(9)
• scmi_revision_area_get(9)
• scmi_protocol_version_negotiate(9)
• scmi_protocol_version_initialize(9)
• scmi_get_protocol_instance(9)
• scmi_protocol_acquire(9)
• scmi_protocol_release(9)
• scmi_devm_protocol_get(9)
• scmi_devm_protocol_acquire(9)
• scmi_devm_protocol_put(9)
• scmi_is_transport_atomic(9)
• scmi_handle_get(9)
• scmi_handle_put(9)
• scmi_channels_setup(9)

---

okay that's the whole page, you ate that 💅💖 go forth and allocate responsibly. this came from ./drivers/firmware/arm_scmi, dated October 2026 — mark your calendars bestie, it's an icon, it's a legend, it's a kernel API manual page 🎀✨🦋