Re: [PATCH 1/2] soc: qcom: qmi: Fix "invalid data length" in encoder

[Jeff Johnson]

On 2/19/2026 11:18 AM, Bjorn Andersson wrote:
> I reviewed the downstream code generator source and documentation.
> 
> We do generate tables matching the ath12k c-structures, i.e. variable
> length arrays are always prefixed with an uint32_t field - not a
> uint8_t or uint16_t based on elem_size.
> 
> Looking back at the original implementation of the in-kernel
> qmi_encode(), we only read elem_size bytes from the c-structure, but we
> do so into the (little-endian) uint32_t on the stack, from which we
> encode the message and act upon the result.
> 
> In qmi_decode() we decode elem_size bytes from the message into the
> (little endian) uint32_t and then write 4 bytes to the c-structure.
> 
> 
> The fix would as such seem to be to just update the length fields to be
> all uint32_t. The problem I see with this is that qmic [1] is the only
> publicly available code generator, and if we change it to always
> generate uint32_t length members, we also need to fix the
> encoder/decoder in libqrtr [2] - which will be an ABI breaking change.

And IMO that is a deal breaker since it would break the interface with all
existing legacy firmware.

> 
> If we go the other way around, the drawback is that we no longer support
> the c-structures generated by the proprietary code generator.
> 
> Worth pointing out is that the structure of the c-code is an ABI between
> the encoder/decoder, the code generator and the client - it does not
> affect the wire format.
> 
> [1] https://github.com/linux-msm/qmic
> [2] https://github.com/linux-msm/qrtr

Going back to the original implementation that reads and writes a u32 on the
stack, can we stick with that but add endian logic that correctly converts
between u32 host endian on the stack and either u8 or u16 little endian in the
messages? Is this specific to QMI_DATA_LEN TLVs?

/jeff