scmi_notifier_register(9)

✨ scmi_notifier_register(9) — the "sign me up for this event bestie" page ✨

okay so real talk, this one lives in the Kernel API Manual and it's genuinely one of those little glue functions that makes the whole SCMI notification machine go brrr. Let's get into it 💅

---

🌸 NAME 🌸

scmi_notifier_register — register a notifier_block for an event, that's literally it, that's the whole vibe 🎀

---

⭐ SYNOPSIS ⭐

int scmi_notifier_register (const struct scmi_handle *handle , u8
proto_id , u8 evt_id , const u32 *src_id , struct notifier_block *nb );

like yes it's five arguments, don't panic, we're gonna go through every single one 👑

---

🦋 ARGUMENTS 🦋

• handle — the handle that identifies which platform instance you're registering the callback against. it's giving "who am I even talking to" energy, and the answer is this parameter 🫶
• proto_id — Protocol ID. yep. just the protocol id.
• evt_id — Event ID. also does exactly what it says on the tin ✨
• src_id — Source ID. important detail: when it's NULL, you're registering for events coming from ALL possible sources. all of them. every last one 🙈
• nb — a standard notifier_block that you register for the specified event. standard. not fancy. still iconic 💖

---

💜 DESCRIPTION 💜

so this is a generic helper that registers a notifier_block against a protocol event. no cap, that's the whole job.

A notifier_block nb gets registered for each distinct event identified by the tuple (proto_id, evt_id, src_id), and each one goes on its own dedicated notification chain, so that:

(proto_X, evt_Y, src_Z) --> chain_X_Y_Z

the meaning of src_id is protocol specific — it identifies the origin of the event, like domain_id, sensor_id and so forth. iykyk 🔥

and here's the slay part: src_id can be NULL to signify that the caller is interested in receiving notifications from ALL the available sources for that protocol, OR simply that the protocol doesn't support distinct sources at all. either way, you're covered 🧚

as soon as one user for the specified tuple appears, a handler gets created, and that specific event's generation is enabled at the platform level — unless an associated registered event is found missing 😭 which means the needed protocol is still to be initialized, and the handler has just been registered as still pending. it's giving "we'll call you, we promise" energy 💀

---

🌈 RETURN 🌈

0 on Success. that's it. 0 on Success. periodt 👑

---

🎀 SEE ALSO 🎀

bestie there are so many of them, buckle up, because this list is a whole friend group:

• Kernel file ./drivers/firmware/arm_scmi/notify.c Theory of operation(9)
• struct scmi_notify_instance(9)
• struct events_queue(9)
• struct scmi_event_header(9)
• struct scmi_registered_events_desc(9)
• struct scmi_registered_event(9)
• struct scmi_event_handler(9)
• scmi_lookup_and_call_event_chain(9)
• scmi_process_event_header(9)
• scmi_process_event_payload(9)
• scmi_events_dispatcher(9)
• scmi_notify(9)
• scmi_kfifo_free(9)
• scmi_initialize_events_queue(9)
• scmi_allocate_registered_events_desc(9)
• scmi_register_protocol_events(9)
• scmi_deregister_protocol_events(9)
• scmi_allocate_event_handler(9)
• scmi_free_event_handler(9)
• scmi_bind_event_handler(9)
• scmi_valid_pending_handler(9)
• scmi_register_event_handler(9)
• __scmi_event_handler_get_ops(9)
• scmi_get_active_handler(9)
• __scmi_enable_evt(9)
• scmi_put_handler_unlocked(9)
• scmi_event_handler_enable_events(9)
• scmi_notifier_unregister(9)
• scmi_devm_notifier_register(9)
• scmi_devm_notifier_unregister(9)
• scmi_protocols_late_init(9)
• scmi_notification_init(9)
• scmi_notification_quiesce(9)
• scmi_notification_exit(9)

go read them. all of them. i'll wait 💅

---

okay that's the whole page!! this little gem ships out of ./drivers/firmware/arm_scmi, dated October 2026 — so like, mark your calendar bestie, and go register some notifiers 🦋💖✨