ath10k Digest, Vol 74, Issue 22

[Bryce Allen]

I have also run into this bug, with two pcengine routers I have with
Compex wireless cards (two ath10k in one and 9k in the other). Note
that the 5.10 kernel ships with Debian 11, so this bug is now in a
default production vendor shipped kernel. One of my boxes runs Ubuntu
LTS, and I rolled back to the 5.4 kernel instead of the HWE kernel to
avoid this issue, and allow my AP to function again. My other box is
Debian and I recently upgraded it to 11 - so now I will need to build or
hunt down a package with an older kernel release, and manually apply
kernel security updates.

I don't know exactly how many users are affected, but it's non-trivial
- pcengines is a great independent Linux device provider, and they have
been selling these wireless cards. It is not their fault that the
wireless card hardware vendor is setting a country code that a kernel
developer decided to interpret in a way that completely disables
functionality for users. I thought the policy was "don't break user
space"; while this is not user space, the sentiment of that I think
should also apply to not break functioning hardware. And this is just
one vendor - I don't know how many other vendors have the 0x0 region.

At the end of the day, I don't care if the wireless card vendors did
the wrong thing putting 0x0 region in their firmware - I want my
hardware, purchased from a vendor that supports Linux and has been for
years, to function like it did before, on modern kernels. The fact that
this patch disallows me to change the region is crazy to me - it would
be one thing if the default failed to be set, but totally breaking the
functionality, I don't understand the justification. Shrugging and
saying it "won't affect that many people" does not seem to fit with the
principals of the Linux kernel.

Meanwhile, I would be interested to know if someone has a good workflow
for out of tree ath9k/10k builds, so I can patch around this without
doing a complete kernel build every time there is a new point release
with security fixes.

Thanks,
Bryce

> On 8/23/21 11:06 PM, Brian Norris wrote:
> Jouni gave a good explanation for why the offending patch is correct, 
> but it hinges on an interpretation of country code 0x0 which seems to
> be incorrect. I followed up on that almost a year ago here[1] but the 
> thread went cold after that.
> 
> Numerous people - myself included - have cited sources clearly 
> indicating that 0x0 = US, NOT unset. See the same post[1] for more
> info.
> 
> I still think this patch should be reverted unless somebody can
> provide a source to the contrary, re: the meaning of 0x0.
> 
> It's unfortunate that this is still affecting users, particularly
> when the original author of the patch even asked for it to be
> reverted.[2]
> 
> 	Alvin
> 
> [1]
> https://lists.infradead.org/pipermail/ath10k/2021-January/012374.html
> [2]
> https://lore.kernel.org/ath10k/9cc7efbb3c9b29e4553a427e6f58725f@codeaurora.org/
> 
> ------------------------------