Re: ath12k: big endian bringup

[Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>]

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