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.
---
Changes in v5:
- Rebase on latest ath master.
- Extend by capturing the basic element handling error codes.

Changes in v4:
- Rebase on latest ath master.
- Drop ath12k patch to make a standalone one.
- Remove `Fixes:` tags as big endian is not yet supported.

Changes in v3:
- Rebase on latest ath master.
- Using a generic encoding/decoding macro causes sparse to complain about
  type violations. Use separate macros for each basic element type instead.

Changes in v2:
- Handle QMI conversion within the QMI subsystem instead of the driver.

Alexander Wilhelm (3):
  soc: qcom: check QMI basic element error codes
  soc: qcom: fix QMI encoding/decoding for basic elements
  soc: qcom: preserve CPU endianness for QMI_DATA_LEN

 drivers/soc/qcom/qmi_encdec.c | 137 +++++++++++++++++++++++++++++-----
 1 file changed, 118 insertions(+), 19 deletions(-)


base-commit: be83ff7549057d184b693a85cafc10fbd520f3d7
-- 
2.43.0

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:

[   21.158943] ipa 1e40000.ipa: received modem running event
[   21.164616] qmi_encode: Invalid data length
[   21.168930] qcom_q6v5_pas remoteproc-adsp: failed to send subsystem event
[   21.175844] qmi_encode: Invalid data length
[   21.180494] qcom_q6v5_pas remoteproc-cdsp: failed to send subsystem event
[   21.187467] qmi_encode: Invalid data length
[   21.191772] qcom-q6v5-mss 4080000.remoteproc: failed to send 
subsystem event
[   21.199088] qmi_encode: Invalid data length
[   21.203360] qcom-q6v5-mss 4080000.remoteproc: failed to send 
subsystem event
[   21.210636] remoteproc remoteproc0: remote processor 
4080000.remoteproc is now up

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.

Thanks
David

[...]--
David Heidelberg

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:
> 
> [   21.158943] ipa 1e40000.ipa: received modem running event
> [   21.164616] qmi_encode: Invalid data length
> [   21.168930] qcom_q6v5_pas remoteproc-adsp: failed to send subsystem event
> [   21.175844] qmi_encode: Invalid data length
> [   21.180494] qcom_q6v5_pas remoteproc-cdsp: failed to send subsystem event
> [   21.187467] qmi_encode: Invalid data length
> [   21.191772] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
> event
> [   21.199088] qmi_encode: Invalid data length
> [   21.203360] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
> event
> [   21.210636] remoteproc remoteproc0: remote processor 4080000.remoteproc
> is now up
> 
> 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.

Hi David,

This is exactly the problem I was afraid of. When the endianness fixes for
`ath12k` were rejected, I implemented them in the QMI subsystem instead. I only
tested this with `ath11k` and `ath12k` drivers, both on little-endian and
big-endian platforms. However, other devices, such as your modem, also rely on
QMI, but were not tested.

The difference now is that, instead of using memcpy, basic elements like `u8`,
`u16`, `u32`, and `u64` are handled explicitly in separate switch-cases. This
raises the question of what exactly the modem and its corresponding driver are
doing at this point. Could you please tell me which repository you are working
on? I could not find `next-20260119` in either the `ath` or the `stable`
repositories.


Best regards
Alexander Wilhelm

On 1/21/26 10:07 AM, Alexander Wilhelm 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:
>>
>> [   21.158943] ipa 1e40000.ipa: received modem running event
>> [   21.164616] qmi_encode: Invalid data length
>> [   21.168930] qcom_q6v5_pas remoteproc-adsp: failed to send subsystem event
>> [   21.175844] qmi_encode: Invalid data length
>> [   21.180494] qcom_q6v5_pas remoteproc-cdsp: failed to send subsystem event
>> [   21.187467] qmi_encode: Invalid data length
>> [   21.191772] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
>> event
>> [   21.199088] qmi_encode: Invalid data length
>> [   21.203360] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
>> event
>> [   21.210636] remoteproc remoteproc0: remote processor 4080000.remoteproc
>> is now up
>>
>> 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.
> 
> Hi David,
> 
> This is exactly the problem I was afraid of. When the endianness fixes for
> `ath12k` were rejected, I implemented them in the QMI subsystem instead. I only
> tested this with `ath11k` and `ath12k` drivers, both on little-endian and
> big-endian platforms. However, other devices, such as your modem, also rely on
> QMI, but were not tested.
> 
> The difference now is that, instead of using memcpy, basic elements like `u8`,
> `u16`, `u32`, and `u64` are handled explicitly in separate switch-cases. This
> raises the question of what exactly the modem and its corresponding driver are
> doing at this point. Could you please tell me which repository you are working
> on? I could not find `next-20260119` in either the `ath` or the `stable`
> repositories.

next-foo comes from linux-next.git

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Konrad

On Wed, Jan 21, 2026 at 10:07:22AM +0100, Alexander Wilhelm 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:
> > 
> > [   21.158943] ipa 1e40000.ipa: received modem running event
> > [   21.164616] qmi_encode: Invalid data length
> > [   21.168930] qcom_q6v5_pas remoteproc-adsp: failed to send subsystem event
> > [   21.175844] qmi_encode: Invalid data length
> > [   21.180494] qcom_q6v5_pas remoteproc-cdsp: failed to send subsystem event
> > [   21.187467] qmi_encode: Invalid data length
> > [   21.191772] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
> > event
> > [   21.199088] qmi_encode: Invalid data length
> > [   21.203360] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
> > event
> > [   21.210636] remoteproc remoteproc0: remote processor 4080000.remoteproc
> > is now up
> > 
> > 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.
> 
> Hi David,
> 
> This is exactly the problem I was afraid of. When the endianness fixes for
> `ath12k` were rejected, I implemented them in the QMI subsystem instead. I only
> tested this with `ath11k` and `ath12k` drivers, both on little-endian and
> big-endian platforms. However, other devices, such as your modem, also rely on
> QMI, but were not tested.
> 
> The difference now is that, instead of using memcpy, basic elements like `u8`,
> `u16`, `u32`, and `u64` are handled explicitly in separate switch-cases. This
> raises the question of what exactly the modem and its corresponding driver are
> doing at this point. Could you please tell me which repository you are working
> on? I could not find `next-20260119` in either the `ath` or the `stable`
> repositories.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20260119


-- 
With best wishes
Dmitry

On Wed, Jan 21, 2026 at 11:27:35AM +0200, Dmitry Baryshkov wrote:
> On Wed, Jan 21, 2026 at 10:07:22AM +0100, Alexander Wilhelm 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:
> > > 
> > > [   21.158943] ipa 1e40000.ipa: received modem running event
> > > [   21.164616] qmi_encode: Invalid data length
> > > [   21.168930] qcom_q6v5_pas remoteproc-adsp: failed to send subsystem event
> > > [   21.175844] qmi_encode: Invalid data length
> > > [   21.180494] qcom_q6v5_pas remoteproc-cdsp: failed to send subsystem event
> > > [   21.187467] qmi_encode: Invalid data length
> > > [   21.191772] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
> > > event
> > > [   21.199088] qmi_encode: Invalid data length
> > > [   21.203360] qcom-q6v5-mss 4080000.remoteproc: failed to send subsystem
> > > event
> > > [   21.210636] remoteproc remoteproc0: remote processor 4080000.remoteproc
> > > is now up
> > > 
> > > 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.
> > 
> > Hi David,
> > 
> > This is exactly the problem I was afraid of. When the endianness fixes for
> > `ath12k` were rejected, I implemented them in the QMI subsystem instead. I only
> > tested this with `ath11k` and `ath12k` drivers, both on little-endian and
> > big-endian platforms. However, other devices, such as your modem, also rely on
> > QMI, but were not tested.
> > 
> > The difference now is that, instead of using memcpy, basic elements like `u8`,
> > `u16`, `u32`, and `u64` are handled explicitly in separate switch-cases. This
> > raises the question of what exactly the modem and its corresponding driver are
> > doing at this point. Could you please tell me which repository you are working
> > on? I could not find `next-20260119` in either the `ath` or the `stable`
> > repositories.
> 
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20260119__;!!I9LPvj3b!AWVWfTEAVZO1j_Z284kxYiMwiOLbmHWEDT8S0RRsUl2rXclrmeyzh9ChVTTXMlhjPLcoRAiuS7Zfx9c0ejF_6IDNCNmVGYaDZmw95gOh$ 

Thanks, Dmitry.

@David:
OK, this is interesting. The QMI subsystem supports exactly the
basic element types from u8 to u64. In your output, I don’t see any errors
like “Unrecognized element size”. Therefore, I assume that the modem is
adhering correctly to the QMI protocol conventions.

The “Invalid data length” error can only occur if `data_len_value <= 0` or
if `temp_ei->elem_len < data_len_value`. However, my changes should not
affect this. Since you are using a Pixel 3, I assume this is a
little-endian platform. Even if your modem performs any endian swapping
internally, this should not affect you.

Unfortunately, I must have overlooked something, I can’t identify the
problem just by reading the code. Without having access to the specific
modem, I’m also unable to debug this properly. As a fallback, you could
revert the changes and drop big-endian support for now. At the moment, I
can’t provide an alternative solution on short notice.


Best regards
Alexander Wilhelm

On Wed, 19 Nov 2025 11:40:04 +0100, 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.
> 
> [...]

Applied, thanks!

[1/3] soc: qcom: check QMI basic element error codes
      commit: 5a6d033c4905d78c9c05b1cab36c7e03951fab9e
[2/3] soc: qcom: fix QMI encoding/decoding for basic elements
      commit: d9c83903be080a6bc25ccabaafe5487836a7e1a7
[3/3] soc: qcom: preserve CPU endianness for QMI_DATA_LEN
      commit: fe099c387e06b566840449ac21008db1b25ad1f4

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>