lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2sjvescdtdo75lpt6e7tnf7c46sj6g3mlakva5nzsa2p643w2@ie4scpc5vhv7>
Date: Sat, 19 Jul 2025 23:24:51 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Jeff Johnson <jeff.johnson@....qualcomm.com>
Cc: Alexander Wilhelm <alexander.wilhelm@...termo.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

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.

Regards,
Bjorn

> /jeff

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ