Message-ID: <aH3uCiv/OaWbt5T8@FUE-ALEWI-WINX>
Date: Mon, 21 Jul 2025 09:36:42 +0200
From: Alexander Wilhelm <alexander.wilhelm@...termo.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Jeff Johnson <jeff.johnson@....qualcomm.com>,
        Jeff Johnson <jjohnson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, linux-wireless@...r.kernel.org,
        ath12k@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 00/11] wifi: ath12k: Fix endianness handling in QMI

Am Sat, Jul 19, 2025 at 11:24:51PM -0500 schrieb Bjorn Andersson:
> On Wed, Jul 16, 2025 at 08:13:20AM -0700, Jeff Johnson wrote:
> > On 7/16/2025 12:50 AM, Alexander Wilhelm wrote:
> > > Fix endianness handling in QMI firmware transfer on big-endian
> > > platforms. Without this fix, the firmware download fails due to
> > > misinterpreted data structures exchanged between the host and the
> > > wireless module.
> > > 
> > > The issue occurs during early bring-up on big endian systems, where QMI
> > > messages are not correctly parsed by the driver, leading to failed
> > > initialization sequences. Ensure all relevant fields are properly
> > > converted between CPU and little-endian format in request and response
> > > messages, as expected by the firmware. Attached logs showing the failure
> > > before the fix:
> > > 
> > >     ath12k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit]
> > >     ath12k_pci 0001:01:00.0: boot pci_mem 0xcd4148e9
> > >     ath12k_pci 0001:01:00.0: pci probe 17cb:1109 17cb:1109
> > >     ath12k_pci 0001:01:00.0: pci tcsr_soc_hw_version major 2 minor 0
> > >     ath12k_pci 0001:01:00.0: request MSI one vector
> > >     ath12k_pci 0001:01:00.0: MSI vectors: 1
> > >     ath12k_pci 0001:01:00.0: msi base data is 0
> > >     ath12k_pci 0001:01:00.0: Hardware name: qcn9274 hw2.0
> > >     ath12k_pci 0001:01:00.0: boot firmware request ath12k/QCN9274/hw2.0/firmware-2.bin size 15134776
> > >     ath12k_pci 0001:01:00.0: found fw timestamp 1722934582
> > >     ath12k_pci 0001:01:00.0: found m3 image ie (421880 B)
> > >     ath12k_pci 0001:01:00.0: found fw image ie (7229440 B)
> > >     ath12k_pci 0001:01:00.0: found dualmac fw image ie (7483392 B)
> > >     ath12k_pci 0001:01:00.0: found firmware features ie (1 B)
> > >     ath12k_pci 0001:01:00.0: features
> > >     ath12k_pci 0001:01:00.0: using fw api 2
> > >     ath12k_pci 0001:01:00.0: dualmac fw selected for board id: 1005
> > >     ath12k_pci 0001:01:00.0: Assign MSI to user: MHI, num_vectors: 3, user_base_data: 0, base_vector: 0
> > >     ath12k_pci 0001:01:00.0: Number of assigned MSI for MHI is 3, base vector is 0
> > >     ath12k_pci 0001:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
> > >     ath12k_pci 0001:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
> > >     ath12k_pci 0001:01:00.0: irq:18 group:0
> > >     ath12k_pci 0001:01:00.0: irq:18 group:1
> > >     ath12k_pci 0001:01:00.0: irq:18 group:2
> > >     ath12k_pci 0001:01:00.0: irq:18 group:3
> > >     ath12k_pci 0001:01:00.0: irq:18 group:4
> > >     ath12k_pci 0001:01:00.0: irq:18 group:5
> > >     ath12k_pci 0001:01:00.0: irq:18 group:6
> > >     ath12k_pci 0001:01:00.0: irq:18 group:7
> > >     ath12k_pci 0001:01:00.0: pci after request_irq msi_ep_base_data 0
> > >     ath12k_pci 0001:01:00.0: cookie:0x0
> > >     ath12k_pci 0001:01:00.0: WLAON_WARM_SW_ENTRY 0x2
> > >     ath12k_pci 0001:01:00.0: WLAON_WARM_SW_ENTRY 0x2
> > >     ath12k_pci 0001:01:00.0: soc reset cause:0
> > >     ath12k_pci 0001:01:00.0: MHISTATUS 0xff04
> > >     ath12k_pci 0001:01:00.0: pci link_ctl 0x0000 L0s 0 L1 0
> > >     ath12k_pci 0001:01:00.0: pci reg 0x3164 instance 0x11 read val 0x11
> > >     ath12k_pci 0001:01:00.0: setting mhi state: INIT(0)
> > >     ath12k_pci 0001:01:00.0: setting mhi state: POWER_ON(2)
> > >     ath12k_pci 0001:01:00.0: mhi notify status reason UNKNOWN
> > >     ath12k_pci 0001:01:00.0: mhi notify status reason MHI_CB_EE_MISSION_MODE
> > >     ath12k_pci 0001:01:00.0: qmi wifi fw qmi service connected
> > >     ath12k_pci 0001:01:00.0: phy capability resp valid 1 num_phy 2 valid 1 board_id 84934656 valid 1 single_chip_mlo_support 0
> > >     ath12k_pci 0001:01:00.0: intra device MLO is disabled hence skip QMI MLO cap
> > > 
> > > Alexander Wilhelm (11):
> > >   wifi: ath12k: fix endianness handling in QMI host capability request
> > >   wifi: ath12k: fix endianness handling in QMI phy capability response
> > >   wifi: ath12k: fix endianness handling in QMI firmware indication
> > >   wifi: ath12k: fix endianness handling in QMI firmware memory indication
> > >   wifi: ath12k: fix endianness handling in QMI respond firmware memory
> > >   wifi: ath12k: fix endianness handling in QMI firmware capabilities
> > >   wifi: ath12k: fix endianness handling in QMI bdf download
> > >   wifi: ath12k: fix endianness handling in QMI firmware m3 info
> > >   wifi: ath12k: fix endianness handling in QMI firmware wlan mode
> > >   wifi: ath12k: fix endianness handling in QMI wlan configuration
> > >   wifi: ath12k: fix endianness handling in QMI response
> > > 
> > >  drivers/net/wireless/ath/ath12k/qmi.c | 149 ++++++++++++++------------
> > >  drivers/net/wireless/ath/ath12k/qmi.h | 106 +++++++++---------
> > >  include/linux/soc/qcom/qmi.h          |   4 +-
> > >  3 files changed, 136 insertions(+), 123 deletions(-)
> > > 
> > 
> > Frankly I'm shocked that the low-level QMI encode/decode is not doing the
> > endian conversion. Since the Qualcomm internal tool that generates the data
> > structures has always generated structs with cpu endianess (i.e. u8, u16, u32,
> > etc) I just assumed that endian conversion was handled at a low level.
> > 
> 
> I'm suspecting that those tools, just like this implementation, is
> exclusively tested on little endian machines...
> 
> > So should this issue be pushed down to the QMI encode/decode rather than foist
> > it upon every client's read & write?
> > 
> 
> It's been a while since I looked at the implementation, but conceptually
> I'm in favor of this.

I could certainly implement the endianness fixes in the QMI code. However, I’m
concerned that other drivers might depend on the current behavior. These changes
could potentially introduce regressions, which I would want to avoid.
Additionally, I’m already seeing some Sparse warnings, and I’m not entirely sure
how to handle them properly at this point.


Best regards
Alexander Wilhelm

Powered by blists - more mailing lists