qmi_encode_message(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… qmi_encode_message(9) β€” like, the Kernel API Manual, bestie ✨

okay so picture this: you're deep in the kernel, you've got a C struct in your hands, and you need it to become a QMI encoded message. That's it. That's the whole vibe. Welcome to qmi_encode_message πŸŽ€


✨ NAME ✨

qmi_encode_message β€” encode a C structure as a QMI encoded message πŸ¦‹


🌸 SYNOPSIS 🌸

void * qmi_encode_message (int type , unsigned int msg_id , size_t *len
, unsigned int txn_id , const struct qmi_elem_info *ei , const void
*c_struct );

πŸ’œ ARGUMENTS πŸ’œ

  • type β€” the type of QMI message πŸ‘‘ like, which flavour we're dealing with
  • msg_id β€” the message ID of the message, iykyk 🏷️
  • len β€” you pass this in as the max length of the message, and it comes back updated to the actual size. she's doing double duty, lowkey iconic πŸ’…
  • txn_id β€” the transaction ID, no cap πŸ”₯
  • ei β€” the QMI message descriptor 🧚 literally the map for the whole encode
  • c_struct β€” reference to the structure you wanna encode 🌈

⭐ RETURN ⭐

A buffer with the encoded message πŸ’– or, if it goes sideways, a negative ERR_PTR on error 😭 fr fr check that pointer.

bestie please: negative ERR_PTR means error, not "a slightly smaller buffer". vibe check your return values πŸ™ˆ

πŸ¦‹ SEE ALSO πŸ¦‹

kernel file ./drivers/soc/qcom/qmi_encdec.c plus the whole friend group: skip_to_next_elem(9), qmi_calc_min_msg_len(9), qmi_encode_basic_elem(9), qmi_encode_struct_elem(9), qmi_encode_string_elem(9), qmi_encode(9), qmi_decode_basic_elem(9), qmi_decode_struct_elem(9), qmi_decode_string_elem(9), find_ei(9), qmi_decode(9), qmi_decode_message(9) 🌸


and that's the page!! 🫢 brought to you from ./drivers/soc/qcom, dated October 2026, in the qmi_encode_message(9) edition β€” slay, go encode something πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from