Re: ath11k: BigEndian platform support?

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

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