Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis <regressions@leemhuis.info>]

Hi, this is your Linux kernel regression tracker speaking.

On 27.11.21 13:21, Nuno Oliveira wrote:
> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>
>> I recently upgraded my Debian based AP from buster to bullseye, just
>> to find out that hostapd does not work any more, because all 5GHz
>> channels are marked as No-IR. This regression was already discussed on
>> this ML here:
>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>> and there is also an entry in Debian's bug tracker for the same issue:
>> https://bugs.debian.org/959821
>>
>> I have a slightly different card (branded Compex WLE200NX):
>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>> Adapter (PCI-Express) (rev 01)
>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>> (PCI-Express)
>>        Kernel driver in use: ath9k
>>        Kernel modules: ath9k
>>
>> But as you can see, also the EEPROM gets sanitized:
>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>> [   15.911600] ath: EEPROM regdomain sanitized
>> [   15.911612] ath: EEPROM regdomain: 0x64
>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>> map
>> [   15.911625] ath: Country alpha2 being used: 00
>> [   15.911628] ath: Regpair used: 0x64
>>
>> I read in the other thread, that this is a regression, but the actual
>> commit causing it was never reverted.
>> I tried to search for newer messages explaining the issue, however as
>> far as I can tell, the thread ends in June 2020 with no solution
>> available.
>>
>> Therefore, I kindly want to ask if there is any workaround available
>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>> a pre-5.6 kernel or manually patching and recompiling ath)
> 
> After June 2020 there were other users also affected by this change (see
> e.g.,
> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
> Users were complaining that this change was too restrictive since it
> meant that the intersection of restrictions for regdomains 0x00, 0x64,
> US, and their local domain, together with a cumulative mode of applying
> these constraints meant that, in practice, they would not be able to use
> their world domain cards anymore as APs in the 5GHz band, for certain
> regdomains where they were located.
> 
> And several people pinpointed the exact source changes responsible for
> this. In my case, I ended up applying the attached patch, that just
> loads the parameters for the regdomain that I'm interested in
> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
> restrictions as much as they are interested in mine.
> 
> So I think that you might be able to use the attached changes, with the
> specific CTRY_xxx parameter suitable for your case. And then recompile
> the respective Debian kernel package, which takes a lot of CPU if you
> just recompile the whole package. Let me know if you need instructions.
> 
> A more robust option would be to go the OpenWRT way, and use their
> patches to make this country selection a parameter for the kernel
> module. This way, you would just reload the kernel module to change to a
> new regdomain, subject to the restrictions of your hardware / firmware.
> I have not looked into that. Please let me know if you isolate these
> patches.
> 
> In any case it seems difficult to escape a kernel recompile, due to this
> small, entirely legitimate, yet remarkable decision by the driver
> maintainers.

This is a regression due to 2dc016599cfa ("ath: add support for special
0x0 regulatory domain") that seems to affect quite a few users, but
afaics was never properly addressed. I fully understand that this might
be a special case where Linus' "no regressions" rule can't be simply
applied.

But isn't there some way to provide users with a solution that doesn't
force users to compile a module or a kernel? Like a module-parameter
that only works if the the regulatory domain code in the EEPROM is empty
(as apparently used by OpenWRT?). Yes, module parameters are normally a
bad idea, but this case it might be a situation where it's the best
solution.

Ciao, Thorsten