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
