qcom_scm_call_atomic(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… qcom_scm_call_atomic(9) β€” Kernel API Manual ✨

Okay bestie, gather ’round β€” this is the Kernel API Manual page for qcom_scm_call_atomic(9), and no cap, every detail is staying. 🫢

🌸 NAME 🌸

qcom_scm_call_atomic β€” atomic variation of qcom_scm_call(), periodt. πŸ’–

✨ SYNOPSIS ✨

The signature, exactly as it appears β€” no edits, no vibes-based renaming, fr fr:

int qcom_scm_call_atomic (struct device *dev , const struct
       qcom_scm_desc *desc , struct qcom_scm_res *res );

πŸŽ€ ARGUMENTS πŸŽ€

  • dev β€” device. That’s the whole note, bestie. 🫢
  • desc β€” descriptor structure containing arguments and return values. It’s giving β€œthe receipts and the results.” πŸ’…
  • res β€” structure containing results from the SMC/HVC call. This is where the tea comes back. β˜•βœ¨

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so here’s the lowkey main character move: qcom_scm_call_atomic sends a command to the SCM and waits for the command to finish processing. That’s it. That’s the vibe. πŸ’«

And the key little sparkle: this can be called in atomic context. So yeah, it’s literally the atomic variation, and that atomic-context line is the whole moment β€” no cap. πŸ”₯

🌈 SEE ALSO 🌈

Kernel file ./drivers/firmware/qcom/qcom_scm.c is in the group chat too. Then the whole bestie lineup is:


Signing off with source/version ./drivers/firmware/qcom and date October 2026 β€” byeee bestie, slay this atomic call! πŸ’…πŸŽ€

πŸ“¦ where this page comes from