Re: ath11k: BigEndian platform support?

Re: ath11k: BigEndian platform support?

[Alexander Wilhelm]

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`.

While working on `ath11k`, I noticed that the firmware swap handling is not
applied consistently. As a result, the driver does not work correctly on big
endian platforms. Based on discussions with Kalle Valo, there is also a risk
that the swap behavior may differ depending on the firmware version in use. To
achieve a stable `ath11k` implementation, Kalle suggested disabling the
firmware-side swapping entirely and restructuring `ath11k` to follow the
`ath12k` approach, by handling endianness exclusively in the driver.

I now have `ath11k` running on a big endian platform and would like to upstream
the corresponding patches to reduce local maintenance. However, the patch set is
quite large (~10k lines), which makes review difficult. My initial idea was to
split the changes into smaller pieces and submit them incrementally. The
challenge is that disabling firmware swapping without simultaneously applying
the full driver-side changes would effectively introduce a regression. Given
that `ath11k` does not currently work on big endian systems anyway, this
“practical regression” might be acceptable, but I would like to hear your
opinion on that.

As an alternative upstreaming approach, I could also imagine sending the patches
via a separate branch, so that the full set of changes can be reviewed and
integrated in a more controlled way. I would appreciate your guidance on how to
best approach upstreaming in this situation, and what would be acceptable from a
reviewer’s perspective before I start sending patches. Additionally, I noticed
that `ath12k` has introduced the `ath12k-ng` branch to separate out Wi-Fi 7
parts and prepare for future Wi-Fi 8 functionality. Since `ath12k` originally
evolved from `ath11k`, are there any plans to consolidate the two, or will
`ath11k` continue as a separate codebase going forward?


Best regards
Alexander Wilhelm

Re: 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@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

Re: ath11k: BigEndian platform support?

[Alexander Wilhelm]

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