__scmi_event...dler_get_ops(9)

🌸 __scmi_event...dler_get_ops(9) 🌸

okay bestie, welcome to the Kernel API Manual ✨ (yes, the kernel has lore now, and you're gonna eat this up 💅). This is the page for __scmi_event...dler_get_ops(9) — the little utility that goes and finds you an event handler, or literally makes one from scratch if you ask nicely 🫶

---

💖 NAME 💖

__scmi_event_handler_get_ops — the utility that gets you an event handler or creates one, whichever the vibe check demands 🔥

---

✨ SYNOPSIS ✨

struct scmi_event_handler * __scmi_event_handler_get_ops (struct
       scmi_notify_instance *ni , u32 evt_key , bool create );

---

🎀 ARGUMENTS 🎀

• ni — a reference to the notification instance you're gonna use 💫
• evt_key — the event key, like the handler's little name tag 🏷️
• create — a boolean flag that says "bestie, if it doesn't exist yet, make it exist" 🙈

---

🦋 DESCRIPTION 🦋

So here's the plan: it searches for the handler you want (matching by key, obviously) in both places — the per-protocol registered table and the common pending table 👑

• if it's found, it adjusts the users refcount 💖
• if it's not found and create is true, it creates and registers the new handler — and heads up, that handler could end up registered as pending if no matching event could be found 🫠

Okay and this next part is important, so listen up 📢 An handler is guaranteed to live in one and only one of the tables at any one time. To make that happen, the whole search-and-create situation is performed while holding the pending_mtx lock, with registered_mtx additionally acquired if needed 🔒🔒

And when a nested acquisition of these mutexes is needed, the locking order is always the same (same as in init_work), no cap:

1. pending_mtx
2. registered_mtx

🚨 Do NOT go flipping that order around. That's how you get deadlocks, and nobody wants that energy. 🚨

Also, events generation is NOT enabled right after creation within this routine — because at creation time we usually want all the setup done and ready before the events really start flowing 🌊 Like, let her get dressed first, damn 💅

---

💀 RETURN 💀

A properly refcounted handler on Success, ERR_PTR on Failure 😭 (yes, failure is possible, it's giving plot twist)

---

🌈 SEE ALSO 🌈

So many friends, so much scrolling, iykyk 💜

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_get_active_handler(9), __scmi_enable_evt(9), scmi_put_handler_unlocked(9), scmi_event_handler_enable_events(9), scmi_notifier_register(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)

---

🌸 okay that's the whole thing, you're officially educated 🌸 Sourced straight from ./drivers/firmware/arm_scmi, dated October 2026, and filed under __scmi_event...dler_get_ops(9). go forth and handle your events, queen 👑💖