From: Alexander Wilhelm <alexander.wilhelm@westermo.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: David Heidelberg <david@ixit.cz>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/3] soc: qcom: extend interface for big endian support
Date: Wed, 21 Jan 2026 11:34:45 +0100 [thread overview]
Message-ID: <aXCrxXvHCUhvhONe@FUE-ALEWI-WINX> (raw)
In-Reply-To: <sc57szhtetjs5b2xbudbib2dkaspek6eohviy5ab4po66e3oz4@zhlfb2c4avc3>
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
next prev parent reply other threads:[~2026-01-21 10:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 10:40 [PATCH v5 0/3] soc: qcom: extend interface for big endian support Alexander Wilhelm
2025-11-19 10:40 ` [PATCH v5 1/3] soc: qcom: check QMI basic element error codes Alexander Wilhelm
2025-11-19 10:40 ` [PATCH v5 2/3] soc: qcom: fix QMI encoding/decoding for basic elements Alexander Wilhelm
2025-11-19 10:40 ` [PATCH v5 3/3] soc: qcom: preserve CPU endianness for QMI_DATA_LEN Alexander Wilhelm
2026-01-16 21:39 ` [PATCH v5 0/3] soc: qcom: extend interface for big endian support Bjorn Andersson
2026-01-21 8:22 ` David Heidelberg
2026-01-21 9:07 ` Alexander Wilhelm
2026-01-21 9:27 ` Dmitry Baryshkov
2026-01-21 10:34 ` Alexander Wilhelm [this message]
2026-01-27 13:29 ` Konrad Dybcio
2026-02-14 19:26 ` Bjorn Andersson
2026-03-09 10:30 ` Thorsten Leemhuis
2026-03-09 10:42 ` Alexander Wilhelm
2026-08-23 23:36 ` David Heidelberg
2026-08-31 7:40 ` Alexander Wilhelm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXCrxXvHCUhvhONe@FUE-ALEWI-WINX \
--to=alexander.wilhelm@westermo.com \
--cc=andersson@kernel.org \
--cc=david@ixit.cz \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.