Re: ath11k: BigEndian platform support?

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

On Wed, Jul 01, 2026 at 10:08:47AM -0700, Jeff Johnson wrote:
> 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@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.

That's an interesting approach. Unfortunately, the situation with the `ath11k`
driver in the past was that the upstream code never really worked on big-endian
platforms. I can understand why, since only very few people are still using such
architectures today.

However, my concern is that if `ath12k` also performs the byte swapping inside
the firmware, neither I nor the wider community will be able to fix endianness
related issues anymore. In that case, we would have to rely entirely on Qualcomm
to address such problems, which raises the question of how much interest there
still is in supporting big-endian platforms going forward. If big-endian support
is no longer a priority, wouldn't it make just as much sense to perform the
swapping in the host driver instead? For little-endian platforms, this would
effectively be a no-op anyway.


Best regards
Alexander Wilhelm