Re: [PATCH v5 0/3] soc: qcom: extend interface for big endian support
From: David Heidelberg
Date: Sun Aug 23 2026 - 19:36:48 EST
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