ath11k: BigEndian platform support?

[Jeff Johnson]

On 6/29/2026 1:35 AM, Alexander Wilhelm wrote:
> On Tue, Jul 11, 2023 at 11:49:54AM +0300, Kalle Valo wrote:
>> Alexander Wilhelm <alexander.wilhelm at westermo.com> writes:
>>
>>> I am trying to get the QCN9074 module to work on a BigEndian PowerPC
>>> platform. My question would be, has anyone done it yet? If not, what
>>> kind of effort would you estimate for porting or are there any
>>> firmware limitations?
>>
>> This is a good question. The short answer is that it _might_ work with
>> QCN9074 but AFAIK nobody has tested it and I'm not really optimistic.
>>
>> The long answer is that the big endian support in ath11k is implemented
>> in a weird way which I regret big time. The idea is that the firmware
>> does the translation instead of ath11k driver with this flag:
>>
>> /* Host software's Copy Engine configuration. */
>> #ifdef __BIG_ENDIAN
>> #define CE_ATTR_FLAGS CE_ATTR_BYTE_SWAP_DATA
>> #else
>> #define CE_ATTR_FLAGS 0
>> #endif
>>
>> But later I was told that not all firmware branches actually support
>> this feature, sigh. To my knowledge QCA6390 and WCN6855 firmwares do not
>> support this CE_ATTR_BYTE_SWAP_DATA but I'm hoping QCN9074 firmware
>> would support it. Grep for BIG_ENDIAN to see more big endian specific
>> changes.
>>
>> In ath12k the endian support was implemented in a proper way using
>> __le32 type family and cpu_to_le32() & co macros, but it's also
>> untested. It's on my todo list to convert ath11k to do the same but no
>> idea when I'm able to work on it. Patches very welcome.
>>
>> Do let me know if you test ath11k on big endian, I'm very curious to
>> know the results.
> 
> Hello Jeff and the `ath` developers,
> 
> there are still a number of pending patch requests from my side for `ath12k`
> addressing various big endian issues. I assume there may still be gaps that I
> did not uncover during my testing. Nevertheless, `ath12k` is now running stable
> for me in both AP and STA modes, so I have started to look into `ath11k`.

Let me start by addressing ath12k. I have been sitting on your patches because
internally there has been a lot of discussion on this topic. Just this week I
convinced Those That Need Convincing (tm) that your changes are consistent
with the approach that was taken with the rest of ath12k to have the host
driver responsible for all byte swapping. So I'll finally be taking those patches.

HOWEVER, Qualcomm is trying to transition all of our products to be based upon
the upstream driver, and the team responsible for enterprise access points
believes that their KPIs on Big Endian platforms cannot be met with software
byte swapping (my understanding is they currently use hardware swapping in
their out-of-tree driver). So it is possible that ath12k will need to
transition to hardware swapping in the future to meet that need.

I just wanted to share that bit.

Your proposal for ath11k still needs to be discussed, but there is obviously
concern about introducing regressions to code. There will also be impacts on
projects like QSDK and OpenWrt, which are based upon applying patches to the
existing driver, if large portions of ath11k are rewritten.

/jeff