STRUCT SCMI_NOTIFY_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct scmi_notify_ops(9) β€” the Kernel API Manual glow-up

okay bestie, sit down, because we're talking about struct scmi_notify_ops β€” it's a struct from the Kernel API Manual and it literally represents the notifications' operations provided by the SCMI core. it's giving backstage-pass energy for events. πŸŽ€


✨ NAME ✨

struct scmi_notify_ops β€” represents notifications' operations provided by SCMI core. that's it, that's the whole vibe. no cap. πŸ’–


πŸ¦‹ SYNOPSIS πŸ¦‹

struct scmi_notify_ops {
    int (*devm_event_notifier_register)(struct scmi_device *sdev, u8 proto_id, u8 evt_id, const u32 *src_id, struct notifier_block *nb);
    int (*devm_event_notifier_unregister)(struct scmi_device *sdev, struct notifier_block *nb);
    int (*event_notifier_register)(const struct scmi_handle *handle, u8 proto_id, u8 evt_id, const u32 *src_id, struct notifier_block *nb);
    int (*event_notifier_unregister)(const struct scmi_handle *handle, u8 proto_id, u8 evt_id, const u32 *src_id, struct notifier_block *nb);
 };

like… look at her. five members. she's organized. she's iconic. πŸ”₯


πŸ‘‘ Members πŸ‘‘

pretend this is the group chat intro round, okay? every member gets their moment:

  • devm_event_notifier_register β€” Managed registration of a notifier_block for the requested event. lowkey the responsible one: she registers AND handles the cleanup energy for you. 🫢
  • devm_event_notifier_unregister β€” Managed unregistration of a notifier_block for the requested event. the "we're done here, thank you next" of the group. πŸ’…
  • event_notifier_register β€” Register a notifier_block for the requested event. no devm_ prefix, no hand-holding, just pure main character initiative. ✨
  • event_notifier_unregister β€” Unregister a notifier_block for the requested event. the un-register. the goodbye. the closure. 🌸

πŸ’€ Description πŸ’€

so, a user can register/unregister its own notifier_block against the wanted platform instance, regarding the desired event identified by the tuple:

(proto_id, evt_id, src_id)

using the provided register/unregister interface β€” where, bestie, lemme explain:

src_id can be provided as NULL if it simply does NOT make sense for the protocol at hand, OR if the user is explicitly interested in receiving notifications from ANY existent source associated to the specified proto_id / evt_id. two whole reasons, both valid, we love a flexible argument. πŸ™ˆ

Received notifications are finally delivered to the registered users, invoking the callback provided with the notifier_block *nb as follows:

int user_cb(nb, evt_id, report)

with:

ngl that's exactly where the original page ends the sentence β€” it says "with:" and then nothing, so we're all just sitting here waiting for the rest of the message to send 😭 not me refreshing the thread

🌈 SEE ALSO 🌈

Kernel file ./include/linux/scmi_protocol.h β€” and honestly the whole friend group showed up, so let's give them their shoutouts:

  • struct scmi_base_info(9)
  • struct scmi_clk_proto_ops(9)
  • struct scmi_perf_proto_ops(9)
  • struct scmi_power_proto_ops(9)
  • struct scmi_sensor_reading(9)
  • struct scmi_range_attrs(9)
  • struct scmi_sensor_axis_info(9)
  • struct scmi_sensor_intervals_info(9)
  • struct scmi_sensor_info(9)
  • struct scmi_sensor_proto_ops(9)
  • struct scmi_reset_proto_ops(9)
  • struct scmi_voltage_info(9)
  • struct scmi_voltage_proto_ops(9)
  • struct scmi_powercap_info(9)
  • struct scmi_powercap_proto_ops(9)
  • struct scmi_pinctrl_proto_ops(9)
  • struct scmi_handle(9)
  • module_scmi_driver(9)
  • module_scmi_protocol(9)

and that's the page, bestie! πŸ’œ quick sign-off receipt: this one lives in ./include/linux, dated October 2026, and yes the footer still reads struct scmi_notify_ops(9) because the title never left the chat. slay, go register something. 🧚⭐

πŸ“¦ where this page comes from