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

[Alexander Wilhelm <alexander.wilhelm@westermo.com>]

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


Best regards
Alexander Wilhelm