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
