qcom_smem_state_register(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ qcom_smem_state_register(9) ✨

okay bestie, welcome to the kernel API manual, the qcom_smem_state_register(9) page specifically πŸ’… this one lives in the Kernel API Manual and honestly? it's a little baddie.


πŸ’– NAME πŸ’–

qcom_smem_state_register β€” register a new state πŸŽ€

like, it literally makes a new state happen. that's the whole vibe. no cap.


🌸 SYNOPSIS 🌸

struct qcom_smem_state * qcom_smem_state_register (struct device_node
*of_node , const struct qcom_smem_state_ops *ops , void *priv );

it hands you back a struct qcom_smem_state *, which is your shiny new state pointer ✨ main character return value energy, fr fr.


πŸ¦‹ ARGUMENTS πŸ¦‹

  • of_node β€” the of_node used for matching client lookups πŸ‘€ that's its whole job, it's the matchmaker of this situation.
  • ops β€” the implementation ops πŸ’… the actual behaviour bits.
  • priv β€” implementation specific private data 🫢 your very own stuff, tucked in there, yours to define.

πŸ”₯ SEE ALSO πŸ”₯

the girlies you should also be looking at, in the kernel file ./drivers/soc/qcom/smem_state.c:

iykyk β€” go read those too, they're all part of the same little friend group 🌈⭐


bestie reminder: of_node is specifically for matching client lookups, ops is the implementation ops, and priv is your implementation specific private data. three arguments, three jobs, no overlap, we love a clear division of labour πŸ’œ

and that's the whole page, you ate that πŸ“ this little beauty comes from ./drivers/soc/qcom, dated October 2026 β€” so go forth, register your state, and slay πŸ’…πŸ‘‘πŸ§š

πŸ“¦ where this page comes from