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
