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

Bjorn Andersson <[email protected]>
Newsgroups org.infradead.lists.ath11k,org.infradead.lists.ath12k,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel
Message-ID <q2gogah4suu3nftewye2l3iud2nxwdi7ykzqnagnz7npmrurgm@7icn643kozp6>
On Wed, Feb 18, 2026 at 10:00:22AM -0800, Jeff Johnson wrote:
> On 2/16/2026 7:25 AM, Bjorn Andersson wrote:
> > It might very well be that the underlying bug is my expectation that
> > elem_size should be reflected in the struct and not only in the encoded
> > message, and hence what I wrote in https://github.com/linux-msm/qmic.
> > Perhaps the length-specifier of an array should always be u32?
> > 
> > @Chris, what does the downstream generator produce here?
> 
> Is this behavior just constrained to QMI_DATA_LEN TLVs?
> 
> I'm looking at downstream Android WLAN code and it has the same discrepancy,
> so it appears the code generator is always producing a u32 member in the host
> struct to hold a QMI_DATA_LEN member even though the actual element size as
> defined in the qmi_elem_info array is either sizeof(u8) or sizeof(u16).
> 
> Does this issue get fixed if we change the member in the host struct, i.e. for
> the issue mentioned (that I chopped off) modify:
> struct qmi_wlanfw_request_mem_ind_msg_v01 {
> -	u32 mem_seg_len;
> +	u8 mem_seg_len;
> 

Yes, that would fix the problem.

But if your elem_info arrays are coming from the downstream tool, then I
think the correct way to fix this would be to move in the other
direction and turn some those u8/u16 members elsewhere into u32.

I have the downstream code generator source here somewhere...

Regards,
Bjorn
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.