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

[Alexander Wilhelm]

On Mon, Aug 24, 2026 at 01:36:38AM +0200, David Heidelberg wrote:
> 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?

Yes, that is correct.


Best regards
Alexander Wilhelm