* ath12k: big endian bringup
@ 2025-06-03 14:31 Alexander Wilhelm
2025-06-04 17:30 ` Jeff Johnson
0 siblings, 1 reply; 5+ messages in thread
From: Alexander Wilhelm @ 2025-06-03 14:31 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k
Hello devs,
I need help to bring up the QCN9274 with ath12k driver on big endian PowerPC
platform. I've already found some issues and fixed the MHI start procedure [1]
and QMI conversion [2]. Furthermore I added some endianness fixes on 'qmi.c'
file and could successfully transfer the firmware and boardfile to the wireless
module. But the firmware does not start properly.
I'm trying to analyze the error and don't fully understand what is happening.
While 'ath12k_htc_connect_service' I expect a successful response from
'ath12k_htc_send', but the connection then is timeout. It seems that I should
receive a message with length of 20 and at least I get one. But then the driver
remains endless in the 'ath12k_ce_recv_process_cb' and I always get a message of
length 0 from the 'ath12k_hal_ce_dst_status_get_length' until RCU stall happens.
More interesting is the 'CE_ATTR_BYTE_SWAP_DATA' from ath11k, that is still used
in ath12k code, but HAL structures now are swapped in driver itself at the same
time. Is that correct?
Please, if anyone could give me a hint, what do I need to look for to fix the
problem? Here are the logs with ATH12K_DBG_ANY level:
user@host:~# modprobe ath12k && logread -fe ath12k_pci
ath12k_pci 0002:01:00.0: qmi firmware request memory request
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 29360128
ath12k_pci 0002:01:00.0: qmi mem seg type 4 size 4145152
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 12582912
ath12k_pci 0002:01:00.0: qmi mem seg type 3 size 1048576
ath12k_pci 0002:01:00.0: qmi mem seg type 10 size 8192
ath12k_pci 0002:01:00.0: qmi dma allocation failed (29360128 B type 1), will try later with small size
ath12k_pci 0002:01:00.0: qmi delays mem_request 5
ath12k_pci 0002:01:00.0: qmi firmware request memory request
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 1048576
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 1 size 1048576
ath12k_pci 0002:01:00.0: qmi mem seg type 4 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 4 size 2048000
ath12k_pci 0002:01:00.0: qmi mem seg type 3 size 1048576
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 9 size 2097152
ath12k_pci 0002:01:00.0: qmi mem seg type 10 size 8192
ath12k_pci 0002:01:00.0: memory type 10 not supported
ath12k_pci 0002:01:00.0: qmi req mem_seg[0] 0x0000000003e00000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[1] 0x0000000004000000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[2] 0x0000000004200000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[3] 0x0000000004400000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[4] 0x0000000004600000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[5] 0x0000000004800000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[6] 0x0000000004a00000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[7] 0x0000000004c00000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[8] 0x0000000004e00000 1048576 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[9] 0x0000000005000000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[10] 0x0000000005200000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[11] 0x0000000005400000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[12] 0x0000000005600000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[13] 0x0000000005800000 2097152 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[14] 0x0000000004f00000 1048576 1
ath12k_pci 0002:01:00.0: qmi req mem_seg[15] 0x0000000005a00000 2097152 4
ath12k_pci 0002:01:00.0: qmi req mem_seg[16] 0x0000000005c00000 2048000 4
ath12k_pci 0002:01:00.0: qmi req mem_seg[17] 0x0000000005e00000 1048576 3
ath12k_pci 0002:01:00.0: qmi req mem_seg[18] 0x0000000006000000 2097152 9
ath12k_pci 0002:01:00.0: qmi req mem_seg[19] 0x0000000006200000 2097152 9
ath12k_pci 0002:01:00.0: qmi req mem_seg[20] 0x0000000006400000 2097152 9
ath12k_pci 0002:01:00.0: qmi req mem_seg[21] 0x0000000006600000 2097152 9
ath12k_pci 0002:01:00.0: qmi req mem_seg[22] 0x0000000006800000 2097152 9
ath12k_pci 0002:01:00.0: qmi req mem_seg[23] 0x0000000006a00000 2097152 9
ath12k_pci 0002:01:00.0: qmi req mem_seg[24] 0x0000000000000000 8192 10
ath12k_pci 0002:01:00.0: qmi firmware memory ready indication
ath12k_pci 0002:01:00.0: devmem [0] start 0x10e000 size 8192
ath12k_pci 0002:01:00.0: devmem [1] start 0x0 size 0
ath12k_pci 0002:01:00.0: devmem [2] start 0x0 size 0
ath12k_pci 0002:01:00.0: devmem [3] start 0x0 size 0
ath12k_pci 0002:01:00.0: qmi cal data supported from eeprom
ath12k_pci 0002:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x3 soc_id 0x401a2200
ath12k_pci 0002:01:00.0: fw_version 0x111300d6 fw_build_timestamp 2024-08-06 08:43 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
ath12k_pci 0002:01:00.0: SMBIOS bdf variant name not set.
ath12k_pci 0002:01:00.0: boot using board name 'bus=pci,qmi-chip-id=0,qmi-board-id=3'
ath12k_pci 0002:01:00.0: boot firmware request ath12k/QCN9274/hw2.0/board-2.bin size 374164
ath12k_pci 0002:01:00.0: board name
ath12k_pci 0002:01:00.0: board name
ath12k_pci 0002:01:00.0: board name
ath12k_pci 0002:01:00.0: boot found match regdb data for name 'bus=pci,qmi-chip-id=0,qmi-board-id=3'
ath12k_pci 0002:01:00.0: boot found regdb data for 'bus=pci,qmi-chip-id=0,qmi-board-id=3'
ath12k_pci 0002:01:00.0: fetched regdb
ath12k_pci 0002:01:00.0: qmi bdf_type 4
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 4
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 19512
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 4
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 13368
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 4
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 7224
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 4
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 1080
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 4
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 0
ath12k_pci 0002:01:00.0: qmi BDF download sequence completed
ath12k_pci 0002:01:00.0: boot using board name 'bus=pci,qmi-chip-id=0,qmi-board-id=3'
ath12k_pci 0002:01:00.0: boot firmware request ath12k/QCN9274/hw2.0/board-2.bin size 374164
ath12k_pci 0002:01:00.0: board name
ath12k_pci 0002:01:00.0: board name
ath12k_pci 0002:01:00.0: board name
ath12k_pci 0002:01:00.0: boot found match board data for name 'bus=pci,qmi-chip-id=0,qmi-board-id=3'
ath12k_pci 0002:01:00.0: boot found board data for 'bus=pci,qmi-chip-id=0,qmi-board-id=3'
ath12k_pci 0002:01:00.0: using board api 2
ath12k_pci 0002:01:00.0: qmi bdf_type 0
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 94208
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 88064
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 81920
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 75776
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 69632
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 63488
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 57344
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 51200
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 45056
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 38912
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 32768
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 26624
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 20480
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 14336
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 8192
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 2048
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 0
ath12k_pci 0002:01:00.0: qmi bdf download request remaining 0
ath12k_pci 0002:01:00.0: qmi BDF download sequence completed
ath12k_pci 0002:01:00.0: qmi bdf download req fixed addr type 3
ath12k_pci 0002:01:00.0: qmi caldata downloaded: type: 3
ath12k_pci 0002:01:00.0: qmi firmware ready
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: CE, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 11,ring_num 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 12,ring_num 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 5,ring_num 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 5,ring_num 1
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 5,ring_num 2
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: multiple msi_groups share one msi, msi_group_num 2
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 5,ring_num 3
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: multiple msi_groups share one msi, msi_group_num 3
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 2,ring_num 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: multiple msi_groups share one msi, msi_group_num 3
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: multiple msi_groups share one msi, msi_group_num 3
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: ring not part of an ext_group; ring_type: 3,ring_num 0
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: multiple msi_groups share one msi, msi_group_num 3
ath12k_pci 0002:01:00.0: Assign MSI to user: DP, num_vectors: 1, user_base_data: 0, base_vector: 0
ath12k_pci 0002:01:00.0: multiple msi_groups share one msi, msi_group_num 3
ath12k_pci 0002:01:00.0: boot htc service 'Control' ul pipe 0 dl pipe 1 eid 0 ready
ath12k_pci 0002:01:00.0: boot htc service 'Control' eid 0 TX flow control disabled
ath12k_pci 0002:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
ath12k_pci 0002:01:00.0: rx ce pipe 1 len 20
ath12k_pci 0002:01:00.0: Target ready! transmit resources: 4 size:4096
ath12k_pci 0002:01:00.0: boot htc service HTT Data does not allocate target credits
ath12k_pci 0002:01:00.0: Service connect timeout
ath12k_pci 0002:01:00.0: failed to connect to HTT: -110
Best regards
Alexander Wilhelm
---
[1] https://lore.kernel.org/mhi/48a98603-d2b0-c279-6b04-0c89baf32d05@oss.qualcomm.com
[2] https://lore.kernel.org/linux-arm-msm/20250522143530.3623809-1-alexander.wilhelm@westermo.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ath12k: big endian bringup
2025-06-03 14:31 ath12k: big endian bringup Alexander Wilhelm
@ 2025-06-04 17:30 ` Jeff Johnson
2025-06-05 6:23 ` Alexander Wilhelm
0 siblings, 1 reply; 5+ messages in thread
From: Jeff Johnson @ 2025-06-04 17:30 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson; +Cc: linux-wireless, ath12k
On 6/3/2025 7:31 AM, Alexander Wilhelm wrote:
> Hello devs,
>
> I need help to bring up the QCN9274 with ath12k driver on big endian PowerPC
> platform. I've already found some issues and fixed the MHI start procedure [1]
> and QMI conversion [2]. Furthermore I added some endianness fixes on 'qmi.c'
> file and could successfully transfer the firmware and boardfile to the wireless
> module. But the firmware does not start properly.
>
> I'm trying to analyze the error and don't fully understand what is happening.
> While 'ath12k_htc_connect_service' I expect a successful response from
> 'ath12k_htc_send', but the connection then is timeout. It seems that I should
> receive a message with length of 20 and at least I get one. But then the driver
> remains endless in the 'ath12k_ce_recv_process_cb' and I always get a message of
> length 0 from the 'ath12k_hal_ce_dst_status_get_length' until RCU stall happens.
>
> More interesting is the 'CE_ATTR_BYTE_SWAP_DATA' from ath11k, that is still used
> in ath12k code, but HAL structures now are swapped in driver itself at the same
> time. Is that correct?
That does NOT sound correct.
What happens if you unconditionally keep the BYTE_SWAP flag disabled?
Note that to date the ath12k driver has not been tested internally on a big
endian host. But your message at least has folks talking about it now...
/jeff
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ath12k: big endian bringup
2025-06-04 17:30 ` Jeff Johnson
@ 2025-06-05 6:23 ` Alexander Wilhelm
2025-06-06 5:18 ` Vasanthakumar Thiagarajan
0 siblings, 1 reply; 5+ messages in thread
From: Alexander Wilhelm @ 2025-06-05 6:23 UTC (permalink / raw)
To: Jeff Johnson; +Cc: Jeff Johnson, linux-wireless, ath12k
Am Wed, Jun 04, 2025 at 10:30:40AM -0700 schrieb Jeff Johnson:
> On 6/3/2025 7:31 AM, Alexander Wilhelm wrote:
> > Hello devs,
> >
> > I need help to bring up the QCN9274 with ath12k driver on big endian PowerPC
> > platform. I've already found some issues and fixed the MHI start procedure [1]
> > and QMI conversion [2]. Furthermore I added some endianness fixes on 'qmi.c'
> > file and could successfully transfer the firmware and boardfile to the wireless
> > module. But the firmware does not start properly.
> >
> > I'm trying to analyze the error and don't fully understand what is happening.
> > While 'ath12k_htc_connect_service' I expect a successful response from
> > 'ath12k_htc_send', but the connection then is timeout. It seems that I should
> > receive a message with length of 20 and at least I get one. But then the driver
> > remains endless in the 'ath12k_ce_recv_process_cb' and I always get a message of
> > length 0 from the 'ath12k_hal_ce_dst_status_get_length' until RCU stall happens.
> >
> > More interesting is the 'CE_ATTR_BYTE_SWAP_DATA' from ath11k, that is still used
> > in ath12k code, but HAL structures now are swapped in driver itself at the same
> > time. Is that correct?
>
> That does NOT sound correct.
> What happens if you unconditionally keep the BYTE_SWAP flag disabled?
Hi Jeff,
I tried to do so, but nothing changed. I will verify whether big endian platform
sets the 'CE_ATTR_BYTE_SWAP_DATA' bit inside of 'attr_flags' at all.
ath12k_pci 0002:01:00.0: rx ce pipe 1 len 20
ath12k_pci 0002:01:00.0: Target ready! transmit resources: 4 size:4096
ath12k_pci 0002:01:00.0: boot htc service HTT Data does not allocate target credits
ath12k_pci 0002:01:00.0: Service connect timeout
ath12k_pci 0002:01:00.0: failed to connect to HTT: -110
But I found the problem for the above log in HAL. I set the '__le32' type for
the 'ht_addr' and 'hp_addr' from 'struct hal_srng.dst_ring' and 'struct
hal_srng.src_ring'. Now I am one step further and have some capabilities issue.
By the way, maybe you can help me here. The function
'ath12k_pull_mac_phy_cap_svc_ready_ext' differs now from the respective one in
ath11k to overcome the endianness problem. But the following lines are
questionable:
cap_band->he_cap_info[0] = le32_to_cpu(mac_caps->he_cap_info_2g);
cap_band->he_cap_info[1] = le32_to_cpu(mac_caps->he_cap_info_2g_ext);
The same for 5G and 6G frequency bands. But it seems that the usespace requires
here '__le16' instead of '__le32' ones. Can you verify that? Or maybe I
misunderstood something.
Best regards
Alexander Wilhelm
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ath12k: big endian bringup
2025-06-05 6:23 ` Alexander Wilhelm
@ 2025-06-06 5:18 ` Vasanthakumar Thiagarajan
2025-06-06 7:36 ` Alexander Wilhelm
0 siblings, 1 reply; 5+ messages in thread
From: Vasanthakumar Thiagarajan @ 2025-06-06 5:18 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson; +Cc: Jeff Johnson, linux-wireless, ath12k
On 6/5/2025 11:53 AM, Alexander Wilhelm wrote:
> Am Wed, Jun 04, 2025 at 10:30:40AM -0700 schrieb Jeff Johnson:
>> On 6/3/2025 7:31 AM, Alexander Wilhelm wrote:
>>> Hello devs,
>>>
>>> I need help to bring up the QCN9274 with ath12k driver on big endian PowerPC
>>> platform. I've already found some issues and fixed the MHI start procedure [1]
>>> and QMI conversion [2]. Furthermore I added some endianness fixes on 'qmi.c'
>>> file and could successfully transfer the firmware and boardfile to the wireless
>>> module. But the firmware does not start properly.
>>>
>>> I'm trying to analyze the error and don't fully understand what is happening.
>>> While 'ath12k_htc_connect_service' I expect a successful response from
>>> 'ath12k_htc_send', but the connection then is timeout. It seems that I should
>>> receive a message with length of 20 and at least I get one. But then the driver
>>> remains endless in the 'ath12k_ce_recv_process_cb' and I always get a message of
>>> length 0 from the 'ath12k_hal_ce_dst_status_get_length' until RCU stall happens.
>>>
>>> More interesting is the 'CE_ATTR_BYTE_SWAP_DATA' from ath11k, that is still used
>>> in ath12k code, but HAL structures now are swapped in driver itself at the same
>>> time. Is that correct?
>>
>> That does NOT sound correct.
>> What happens if you unconditionally keep the BYTE_SWAP flag disabled?
>
> Hi Jeff,
>
> I tried to do so, but nothing changed. I will verify whether big endian platform
> sets the 'CE_ATTR_BYTE_SWAP_DATA' bit inside of 'attr_flags' at all.
Byte swapping will not get enabled in ath12k for big endian platform.
CE_ATTR_BYTE_SWAP_DATA and and other byte swap related macros are ineffective
in ath12k, CE_ATTR_BYTE_SWAP_DATA is not really added in CE_ATTR_FLAGS.
>
> ath12k_pci 0002:01:00.0: rx ce pipe 1 len 20
> ath12k_pci 0002:01:00.0: Target ready! transmit resources: 4 size:4096
> ath12k_pci 0002:01:00.0: boot htc service HTT Data does not allocate target credits
> ath12k_pci 0002:01:00.0: Service connect timeout
> ath12k_pci 0002:01:00.0: failed to connect to HTT: -110
>
> But I found the problem for the above log in HAL. I set the '__le32' type for
> the 'ht_addr' and 'hp_addr' from 'struct hal_srng.dst_ring' and 'struct
> hal_srng.src_ring'. Now I am one step further and have some capabilities issue.
> By the way, maybe you can help me here. The function
> 'ath12k_pull_mac_phy_cap_svc_ready_ext' differs now from the respective one in
> ath11k to overcome the endianness problem. But the following lines are
> questionable:
>
> cap_band->he_cap_info[0] = le32_to_cpu(mac_caps->he_cap_info_2g);
> cap_band->he_cap_info[1] = le32_to_cpu(mac_caps->he_cap_info_2g_ext);
>
> The same for 5G and 6G frequency bands. But it seems that the usespace requires
> here '__le16' instead of '__le32' ones. Can you verify that? Or maybe I
> misunderstood something.
No, it is indeed 4-byte. In total, there will be 6-bytes in mac_cap_info which
populated from two 4-byte information from firmware with some internal data
encoded in MSB two bytes of the second word which will get dropped when advertising
the cap to mac80211 (in memcpy).
Vasanth
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ath12k: big endian bringup
2025-06-06 5:18 ` Vasanthakumar Thiagarajan
@ 2025-06-06 7:36 ` Alexander Wilhelm
0 siblings, 0 replies; 5+ messages in thread
From: Alexander Wilhelm @ 2025-06-06 7:36 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Jeff Johnson, Jeff Johnson, linux-wireless, ath12k
Am Fri, Jun 06, 2025 at 10:48:27AM +0530 schrieb Vasanthakumar Thiagarajan:
>
>
> On 6/5/2025 11:53 AM, Alexander Wilhelm wrote:
> > Am Wed, Jun 04, 2025 at 10:30:40AM -0700 schrieb Jeff Johnson:
> > > On 6/3/2025 7:31 AM, Alexander Wilhelm wrote:
> > > > Hello devs,
> > > >
> > > > I need help to bring up the QCN9274 with ath12k driver on big endian PowerPC
> > > > platform. I've already found some issues and fixed the MHI start procedure [1]
> > > > and QMI conversion [2]. Furthermore I added some endianness fixes on 'qmi.c'
> > > > file and could successfully transfer the firmware and boardfile to the wireless
> > > > module. But the firmware does not start properly.
> > > >
> > > > I'm trying to analyze the error and don't fully understand what is happening.
> > > > While 'ath12k_htc_connect_service' I expect a successful response from
> > > > 'ath12k_htc_send', but the connection then is timeout. It seems that I should
> > > > receive a message with length of 20 and at least I get one. But then the driver
> > > > remains endless in the 'ath12k_ce_recv_process_cb' and I always get a message of
> > > > length 0 from the 'ath12k_hal_ce_dst_status_get_length' until RCU stall happens.
> > > >
> > > > More interesting is the 'CE_ATTR_BYTE_SWAP_DATA' from ath11k, that is still used
> > > > in ath12k code, but HAL structures now are swapped in driver itself at the same
> > > > time. Is that correct?
> > >
> > > That does NOT sound correct.
> > > What happens if you unconditionally keep the BYTE_SWAP flag disabled?
> >
> > Hi Jeff,
> >
> > I tried to do so, but nothing changed. I will verify whether big endian platform
> > sets the 'CE_ATTR_BYTE_SWAP_DATA' bit inside of 'attr_flags' at all.
>
> Byte swapping will not get enabled in ath12k for big endian platform.
> CE_ATTR_BYTE_SWAP_DATA and and other byte swap related macros are ineffective
> in ath12k, CE_ATTR_BYTE_SWAP_DATA is not really added in CE_ATTR_FLAGS.
>
>
> >
> > ath12k_pci 0002:01:00.0: rx ce pipe 1 len 20
> > ath12k_pci 0002:01:00.0: Target ready! transmit resources: 4 size:4096
> > ath12k_pci 0002:01:00.0: boot htc service HTT Data does not allocate target credits
> > ath12k_pci 0002:01:00.0: Service connect timeout
> > ath12k_pci 0002:01:00.0: failed to connect to HTT: -110
> >
> > But I found the problem for the above log in HAL. I set the '__le32' type for
> > the 'ht_addr' and 'hp_addr' from 'struct hal_srng.dst_ring' and 'struct
> > hal_srng.src_ring'. Now I am one step further and have some capabilities issue.
> > By the way, maybe you can help me here. The function
> > 'ath12k_pull_mac_phy_cap_svc_ready_ext' differs now from the respective one in
> > ath11k to overcome the endianness problem. But the following lines are
> > questionable:
> >
> > cap_band->he_cap_info[0] = le32_to_cpu(mac_caps->he_cap_info_2g);
> > cap_band->he_cap_info[1] = le32_to_cpu(mac_caps->he_cap_info_2g_ext);
> >
> > The same for 5G and 6G frequency bands. But it seems that the usespace requires
> > here '__le16' instead of '__le32' ones. Can you verify that? Or maybe I
> > misunderstood something.
>
> No, it is indeed 4-byte. In total, there will be 6-bytes in mac_cap_info which
> populated from two 4-byte information from firmware with some internal data
> encoded in MSB two bytes of the second word which will get dropped when advertising
> the cap to mac80211 (in memcpy).
Yes, you're right. There is 6 and 11 byte arrays for 'mac_cap_info' and
'phy_cap_info' for HE and 2 and 9 byte array for EHT capabilities. They are
wrongly set on big endian due to simple memcpy from u32 to u8 arrays.
Best regards
Alexander Wilhelm
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-06-06 7:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-03 14:31 ath12k: big endian bringup Alexander Wilhelm
2025-06-04 17:30 ` Jeff Johnson
2025-06-05 6:23 ` Alexander Wilhelm
2025-06-06 5:18 ` Vasanthakumar Thiagarajan
2025-06-06 7:36 ` Alexander Wilhelm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox