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

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

[Alexander Wilhelm]

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

[PATCH v5 1/3] soc: qcom: check QMI basic element error codes

[Alexander Wilhelm]

Extend handling of QMI basic element types to also capture error codes.
This is required for big-endian platforms where a simple memcpy is not
sufficient and exact data type knowledge is necessary.

Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
---
 drivers/soc/qcom/qmi_encdec.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/soc/qcom/qmi_encdec.c b/drivers/soc/qcom/qmi_encdec.c
index 7660a960fb45..1d2d9e515870 100644
--- a/drivers/soc/qcom/qmi_encdec.c
+++ b/drivers/soc/qcom/qmi_encdec.c
@@ -267,11 +267,15 @@ static int qmi_encode_string_elem(const struct qmi_elem_info *ei_array,
 		}
 		rc = qmi_encode_basic_elem(buf_dst, &string_len,
 					   1, string_len_sz);
+		if (rc < 0)
+			return rc;
 		encoded_bytes += rc;
 	}
 
 	rc = qmi_encode_basic_elem(buf_dst + encoded_bytes, buf_src,
 				   string_len, temp_ei->elem_size);
+	if (rc < 0)
+		return rc;
 	encoded_bytes += rc;
 
 	return encoded_bytes;
@@ -333,6 +337,8 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf,
 		case QMI_OPT_FLAG:
 			rc = qmi_encode_basic_elem(&opt_flag_value, buf_src,
 						   1, sizeof(u8));
+			if (rc < 0)
+				return rc;
 			if (opt_flag_value)
 				temp_ei = temp_ei + 1;
 			else
@@ -354,11 +360,15 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf,
 				data_len_value = (u32)val8;
 				rc = qmi_encode_basic_elem(buf_dst, &val8,
 							   1, data_len_sz);
+				if (rc < 0)
+					return rc;
 			} else {
 				val16 = *(u16 *)buf_src;
 				data_len_value = (u32)le16_to_cpu(val16);
 				rc = qmi_encode_basic_elem(buf_dst, &val16,
 							   1, data_len_sz);
+				if (rc < 0)
+					return rc;
 			}
 			UPDATE_ENCODE_VARIABLES(temp_ei, buf_dst,
 						encoded_bytes, tlv_len,
@@ -386,6 +396,8 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf,
 			rc = qmi_encode_basic_elem(buf_dst, buf_src,
 						   data_len_value,
 						   temp_ei->elem_size);
+			if (rc < 0)
+				return rc;
 			UPDATE_ENCODE_VARIABLES(temp_ei, buf_dst,
 						encoded_bytes, tlv_len,
 						encode_tlv, rc);
@@ -544,10 +556,14 @@ static int qmi_decode_string_elem(const struct qmi_elem_info *ei_array,
 		if (string_len_sz == sizeof(u8)) {
 			rc = qmi_decode_basic_elem(&val8, buf_src,
 						   1, string_len_sz);
+			if (rc < 0)
+				return rc;
 			string_len = (u32)val8;
 		} else {
 			rc = qmi_decode_basic_elem(&val16, buf_src,
 						   1, string_len_sz);
+			if (rc < 0)
+				return rc;
 			string_len = (u32)val16;
 		}
 		decoded_bytes += rc;
@@ -565,6 +581,8 @@ static int qmi_decode_string_elem(const struct qmi_elem_info *ei_array,
 
 	rc = qmi_decode_basic_elem(buf_dst, buf_src + decoded_bytes,
 				   string_len, temp_ei->elem_size);
+	if (rc < 0)
+		return rc;
 	*((char *)buf_dst + string_len) = '\0';
 	decoded_bytes += rc;
 
@@ -667,10 +685,14 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct,
 			if (data_len_sz == sizeof(u8)) {
 				rc = qmi_decode_basic_elem(&val8, buf_src,
 							   1, data_len_sz);
+				if (rc < 0)
+					return rc;
 				data_len_value = (u32)val8;
 			} else {
 				rc = qmi_decode_basic_elem(&val16, buf_src,
 							   1, data_len_sz);
+				if (rc < 0)
+					return rc;
 				data_len_value = (u32)val16;
 			}
 			val32 = cpu_to_le32(data_len_value);
@@ -701,6 +723,8 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct,
 			rc = qmi_decode_basic_elem(buf_dst, buf_src,
 						   data_len_value,
 						   temp_ei->elem_size);
+			if (rc < 0)
+				return rc;
 			UPDATE_DECODE_VARIABLES(buf_src, decoded_bytes, rc);
 			break;
 
-- 
2.43.0

[PATCH v5 2/3] soc: qcom: fix QMI encoding/decoding for basic elements

[Alexander Wilhelm]

Extend the QMI byte encoding and decoding logic to support multiple basic
data type sizes (u8, u16, u32, u64) using differnet macros for each type.
Ensure correct handling of data sizes and proper byte order conversion on
big-endian platforms by consistently applying these macros during encoding
and decoding of basic elements.

Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/soc/qcom/qmi_encdec.c | 102 ++++++++++++++++++++++++++++++----
 1 file changed, 90 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/qcom/qmi_encdec.c b/drivers/soc/qcom/qmi_encdec.c
index 1d2d9e515870..030b18fa086a 100644
--- a/drivers/soc/qcom/qmi_encdec.c
+++ b/drivers/soc/qcom/qmi_encdec.c
@@ -23,18 +23,60 @@
 	*p_length |= ((u8)*p_src) << 8; \
 } while (0)
 
-#define QMI_ENCDEC_ENCODE_N_BYTES(p_dst, p_src, size) \
+#define QMI_ENCDEC_ENCODE_U8(p_dst, p_src) \
 do { \
-	memcpy(p_dst, p_src, size); \
-	p_dst = (u8 *)p_dst + size; \
-	p_src = (u8 *)p_src + size; \
+	memcpy(p_dst, p_src, sizeof(u8)); \
+	p_dst = (u8 *)p_dst + sizeof(u8); \
+	p_src = (u8 *)p_src + sizeof(u8); \
 } while (0)
 
-#define QMI_ENCDEC_DECODE_N_BYTES(p_dst, p_src, size) \
+#define QMI_ENCDEC_ENCODE_U16(p_dst, p_src) \
 do { \
-	memcpy(p_dst, p_src, size); \
-	p_dst = (u8 *)p_dst + size; \
-	p_src = (u8 *)p_src + size; \
+	*(__le16 *)p_dst = __cpu_to_le16(*(u16 *)p_src); \
+	p_dst = (u8 *)p_dst + sizeof(u16); \
+	p_src = (u8 *)p_src + sizeof(u16); \
+} while (0)
+
+#define QMI_ENCDEC_ENCODE_U32(p_dst, p_src) \
+do { \
+	*(__le32 *)p_dst = __cpu_to_le32(*(u32 *)p_src); \
+	p_dst = (u8 *)p_dst + sizeof(u32); \
+	p_src = (u8 *)p_src + sizeof(u32); \
+} while (0)
+
+#define QMI_ENCDEC_ENCODE_U64(p_dst, p_src) \
+do { \
+	*(__le64 *)p_dst = __cpu_to_le64(*(u64 *)p_src); \
+	p_dst = (u8 *)p_dst + sizeof(u64); \
+	p_src = (u8 *)p_src + sizeof(u64); \
+} while (0)
+
+#define QMI_ENCDEC_DECODE_U8(p_dst, p_src) \
+do { \
+	memcpy(p_dst, p_src, sizeof(u8)); \
+	p_dst = (u8 *)p_dst + sizeof(u8); \
+	p_src = (u8 *)p_src + sizeof(u8); \
+} while (0)
+
+#define QMI_ENCDEC_DECODE_U16(p_dst, p_src) \
+do { \
+	*(u16 *)p_dst = __le16_to_cpu(*(__le16 *)p_src); \
+	p_dst = (u8 *)p_dst + sizeof(u16); \
+	p_src = (u8 *)p_src + sizeof(u16); \
+} while (0)
+
+#define QMI_ENCDEC_DECODE_U32(p_dst, p_src) \
+do { \
+	*(u32 *)p_dst = __le32_to_cpu(*(__le32 *)p_src); \
+	p_dst = (u8 *)p_dst + sizeof(u32); \
+	p_src = (u8 *)p_src + sizeof(u32); \
+} while (0)
+
+#define QMI_ENCDEC_DECODE_U64(p_dst, p_src) \
+do { \
+	*(u64 *)p_dst = __le64_to_cpu(*(__le64 *)p_src); \
+	p_dst = (u8 *)p_dst + sizeof(u64); \
+	p_src = (u8 *)p_src + sizeof(u64); \
 } while (0)
 
 #define UPDATE_ENCODE_VARIABLES(temp_si, buf_dst, \
@@ -161,7 +203,8 @@ static int qmi_calc_min_msg_len(const struct qmi_elem_info *ei_array,
  * of primary data type which include u8 - u64 or similar. This
  * function returns the number of bytes of encoded information.
  *
- * Return: The number of bytes of encoded information.
+ * Return: The number of bytes of encoded information on success or negative
+ * errno on error.
  */
 static int qmi_encode_basic_elem(void *buf_dst, const void *buf_src,
 				 u32 elem_len, u32 elem_size)
@@ -169,7 +212,24 @@ static int qmi_encode_basic_elem(void *buf_dst, const void *buf_src,
 	u32 i, rc = 0;
 
 	for (i = 0; i < elem_len; i++) {
-		QMI_ENCDEC_ENCODE_N_BYTES(buf_dst, buf_src, elem_size);
+		switch (elem_size) {
+		case sizeof(u8):
+			QMI_ENCDEC_ENCODE_U8(buf_dst, buf_src);
+			break;
+		case sizeof(u16):
+			QMI_ENCDEC_ENCODE_U16(buf_dst, buf_src);
+			break;
+		case sizeof(u32):
+			QMI_ENCDEC_ENCODE_U32(buf_dst, buf_src);
+			break;
+		case sizeof(u64):
+			QMI_ENCDEC_ENCODE_U64(buf_dst, buf_src);
+			break;
+		default:
+			pr_err("%s: Unrecognized element size\n", __func__);
+			return -EINVAL;
+		}
+
 		rc += elem_size;
 	}
 
@@ -456,7 +516,8 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf,
  * of primary data type which include u8 - u64 or similar. This
  * function returns the number of bytes of decoded information.
  *
- * Return: The total size of the decoded data elements, in bytes.
+ * Return: The total size of the decoded data elements, in bytes, on success or
+ * negative errno on error.
  */
 static int qmi_decode_basic_elem(void *buf_dst, const void *buf_src,
 				 u32 elem_len, u32 elem_size)
@@ -464,7 +525,24 @@ static int qmi_decode_basic_elem(void *buf_dst, const void *buf_src,
 	u32 i, rc = 0;
 
 	for (i = 0; i < elem_len; i++) {
-		QMI_ENCDEC_DECODE_N_BYTES(buf_dst, buf_src, elem_size);
+		switch (elem_size) {
+		case sizeof(u8):
+			QMI_ENCDEC_DECODE_U8(buf_dst, buf_src);
+			break;
+		case sizeof(u16):
+			QMI_ENCDEC_DECODE_U16(buf_dst, buf_src);
+			break;
+		case sizeof(u32):
+			QMI_ENCDEC_DECODE_U32(buf_dst, buf_src);
+			break;
+		case sizeof(u64):
+			QMI_ENCDEC_DECODE_U64(buf_dst, buf_src);
+			break;
+		default:
+			pr_err("%s: Unrecognized element size\n", __func__);
+			return -EINVAL;
+		}
+
 		rc += elem_size;
 	}
 
-- 
2.43.0

[PATCH v5 3/3] soc: qcom: preserve CPU endianness for QMI_DATA_LEN

[Alexander Wilhelm]

To ensure correct handling of endianness in the QMI subsystem, the
QMI_DATA_LEN field used in host-side drivers remains in CPU-native byte
order. Remove unnecessary endianness conversions, considering that
QMI_DATA_LEN is always of type `u32` on the host. On the QMI wire
interface, however, its representation is variable and may use either 1 or
2 bytes.

Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/soc/qcom/qmi_encdec.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/qcom/qmi_encdec.c b/drivers/soc/qcom/qmi_encdec.c
index 030b18fa086a..28ce6f130b6a 100644
--- a/drivers/soc/qcom/qmi_encdec.c
+++ b/drivers/soc/qcom/qmi_encdec.c
@@ -406,6 +406,7 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf,
 			break;
 
 		case QMI_DATA_LEN:
+			memcpy(&data_len_value, buf_src, sizeof(u32));
 			data_len_sz = temp_ei->elem_size == sizeof(u8) ?
 					sizeof(u8) : sizeof(u16);
 			/* Check to avoid out of range buffer access */
@@ -416,15 +417,13 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf,
 				return -ETOOSMALL;
 			}
 			if (data_len_sz == sizeof(u8)) {
-				val8 = *(u8 *)buf_src;
-				data_len_value = (u32)val8;
+				val8 = data_len_value;
 				rc = qmi_encode_basic_elem(buf_dst, &val8,
 							   1, data_len_sz);
 				if (rc < 0)
 					return rc;
 			} else {
-				val16 = *(u16 *)buf_src;
-				data_len_value = (u32)le16_to_cpu(val16);
+				val16 = data_len_value;
 				rc = qmi_encode_basic_elem(buf_dst, &val16,
 							   1, data_len_sz);
 				if (rc < 0)
@@ -721,7 +720,6 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct,
 	int rc;
 	u8 val8;
 	u16 val16;
-	u32 val32;
 
 	while (decoded_bytes < in_buf_len) {
 		if (dec_level >= 2 && temp_ei->data_type == QMI_EOTI)
@@ -773,8 +771,7 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct,
 					return rc;
 				data_len_value = (u32)val16;
 			}
-			val32 = cpu_to_le32(data_len_value);
-			memcpy(buf_dst, &val32, sizeof(u32));
+			memcpy(buf_dst, &data_len_value, sizeof(u32));
 			temp_ei = temp_ei + 1;
 			buf_dst = out_c_struct + temp_ei->offset;
 			tlv_len -= data_len_sz;
-- 
2.43.0

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

[Bjorn Andersson]

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>

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

[David Heidelberg]

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

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

[Alexander Wilhelm]

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

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

[Dmitry Baryshkov]

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

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

[Alexander Wilhelm]

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

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

[Konrad Dybcio]

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

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

[Bjorn Andersson]

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.
> 

#regzbot ^introduced: fe099c387e06

> Thanks
> David
> 
> [...]--
> David Heidelberg
> 

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

[Thorsten Leemhuis]

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?

If no fix is in sight, might it be best to revert this series for now
and reapply it later once a solution was found? I assume that's what
Linus would likely want here at this point.

Ciao, Thorsten

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

[Alexander Wilhelm]

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