qcom_scm_qt...ack_response(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

Okay bestie, this page is qcom_scm_qt...ack_response(9) from the Kernel API Manual, and the function is literally qcom_scm_qtee_callback_response β€” Submit response for callback request. πŸ’…


✨ SYNOPSIS ✨

int qcom_scm_qtee_callback_response (phys_addr_t buf , size_t buf_size ,
       u64 *result , u64 *response_type );

πŸŽ€ ARGUMENTS πŸŽ€

  • buf β€” start address of memory area used for outbound buffer. πŸ“
  • buf_size β€” size of the memory area used for outbound buffer. πŸ“
  • result β€” Result of QTEE object invocation. 🧾
  • response_type β€” Response type returned by QTEE. 🏷️

πŸ¦‹ DESCRIPTION πŸ¦‹

So like, response_type is the main character here: it determines how the contents of buf should be processed. That's the vibe check. ✨


🌸 RETURN 🌸

On success, return 0 or <0 on failure. That's it, that's the whole energy. πŸ’–


πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./drivers/firmware/qcom/qcom_scm.c struct qcom_scm_qseecom_resp(9) β€” plus the whole squad, no cap:


Made with 🫢 from ./drivers/firmware/qcom, dated October 2026, and this has been your qcom_scm_qt...ack_response(9) moment β€” bye bestie! πŸŽ€πŸ¦‹πŸ’œ

πŸ“¦ where this page comes from