Re: ath12k: big endian bringup

[Alexander Wilhelm <alexander.wilhelm@westermo.com>]

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