scmi_events_dispatcher(9)

💅 scmi_events_dispatcher — Kernel API Manual ✨

okay bestie, buckle up, because this is the scmi_events_dispatcher(9) page from the Kernel API Manual and it's honestly kind of a bop once you get it 💖

---

🎀 NAME 🎀

scmi_events_dispatcher — the common worker logic that all the work items share, no cap 🫶

---

✨ SYNOPSIS ✨

void scmi_events_dispatcher (struct work_struct *work );

---

🦋 ARGUMENTS 🦋

• work — the work item you're handing over, and bestie it's tied to its very own dedicated events_queue (not sharing, not borrowing, it's got its own 🌸)

---

💜 DESCRIPTION 💜

okay so here's the literal logic, step by step, and yes I'm numbering them because the manpage numbered them:

1. dequeue ONE pending RX notification (this thing got queued up back in SCMI RX ISR context, just so we're clear 👀)
2. generate a custom event report from the received event message — we're making it cute and bespoke 💅
3. look up any registered ALL_SRC_IDs handler:
   • > call the related notification chain, passing in the report
4. look up any registered specific SRC_ID handler:
   • > call the related notification chain, passing in the report

---

🌈 notes, because there are notes 🌈

• a dedicated per-protocol kfifo queue is used — the whole point is that an anomalous flood of events cannot saturate other protocols' queues. the way that isolation just works 🔥
• each per-protocol queue is associated to a distinct work_item, which means (and this is the part that ate):
  • all protocols can process their dedicated queues concurrently (since notify_wq:max_active != 1)
  • anyway, at most one worker instance is allowed to run on the same queue concurrently: this ensures we can have only one concurrent reader/writer on the associated kfifo, so that we can use it lock-less 👑

---

🧚 CONTEXT 🧚

Process context. that's it. that's the whole section 💀

---

⭐ SEE ALSO ⭐

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_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_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)

that's a lot of cross-refs, and yes I listed every single one, you're welcome 😭💖

---

sign-off time 🎀 this came out of ./drivers/firmware/arm_scmi, dated October 2026, and it's the scmi_events_dispatcher(9) page — periodt. go forth and dispatch, icon 👑🌸