Re: [PATCH v5 0/3] soc: qcom: extend interface for big endian support

On 09/03/2026 11:42, Alexander Wilhelm wrote:
> On Mon, Mar 09, 2026 at 11:30:42AM +0100, Thorsten Leemhuis wrote:
>> On 2/14/26 20:26, Bjorn Andersson wrote:
>>> On Wed, Jan 21, 2026 at 09:22:07AM +0100, David Heidelberg wrote:
>>>> On 19/11/2025 11:40, Alexander Wilhelm wrote:
>>>>> Currently, the QMI interface only works on little endian systems due to how
>>>>> it encodes and decodes data. Most QMI related data structures are defined
>>>>> in CPU native order and do not use endian specific types.
>>>>>
>>>>> Add support for endian conversion of basic element types in the QMI
>>>>> encoding and decoding logic. Fix the handling of QMI_DATA_LEN fields to
>>>>> ensure correct interpretation on big endian systems. These changes are
>>>>> required to allow QMI to operate correctly across architectures with
>>>>> different endianness.
>>>>> ---
>>>>
>>>> Hello,
>>>>
>>>> I recently (next-20260119) started receiving errors on Pixel 3:
>>>> [...]
>>>> Since it's not well tested, I believe there could be problem with
>>>> configuration, but after reverting this series, no errors pop up.
>>>>
>>>> I would believe maybe these errors was previously hidden, but just to be
>>>> sure asking here.
>>>
>>> #regzbot ^introduced: fe099c387e06
>>
>> Looks like nothing much has happened since then – or was there some
>> progress or even a solution I missed?
> 
> The current proposal is that the driver side should always use `u32` for
> all `DATA_LEN` fields. Most drivers already follow this, and Bjorn has
> proposed the patch for the one that was using a different type, and it has
> already been applied.
> 
> Check:
> [1/1] remoteproc: sysmon: Correct subsys_name_len type in QMI request
>        commit: da994db94e60f9a9411108ddf4d1836147ad4c9c

So I assume we can drop:

  - soc: qcom: qmi: Fix "invalid data length" in encoder
  - soc: qcom: qmi: Avoid splatting the "length" destination field

we carry, right?

Thanks
David>
> 
> Best regards
> Alexander Wilhelm