Revert: ath: add support for special 0x0 regulatory domain

Revert: ath: add support for special 0x0 regulatory domain

[Andrey Skvortsov]

Hi,

this patch broke several 5GHz AP in my home based on different Atheros
cards (ath9k and ath10k). Both of them have FCC ID and were purchased from
different suppliers (EU and non-EU) in 2020 and in 2018. I know many other
users are affected as well.

I know this problem was discussed several times already. But I have a
couple of questions.

1) Current behaviour maps 0x0 regulatory domain to the most restrictive
world domain. According to the wiki (probably based on Atheros
documentation) 0x0 means US. Does wiki contain wrong information?

2) If I understand correctly, 0x0 is always replaced with 0x64 and that
makes the following code useless, because it will never be executed. Is it
ok?

drivers/net/wireless/ath/regd.c:703:708

if (reg->country_code == CTRY_DEFAULT &&
        regdmn == CTRY_DEFAULT) {
            printk(KERN_DEBUG "ath: EEPROM indicates default "
                "country code should be used\n");
            reg->country_code = CTRY_UNITED_STATES;
}

3) Previously it was possible to get regulatory information using 'iw reg
get', but now it doesn't work anymore. Is it expected behavior?

[--------------------4.19 ---------------------------------]
# iw reg get
global
country 98: DFS-UNSET
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 100), (N/A, 20), (N/A), NO-OUTDOOR
(5250 - 5350 @ 100), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
(5650 - 5730 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
(5730 - 5850 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
(57240 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR

phy#0
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

phy#1
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)


[--------------------- 5.10 --------------------------------]
#iw reg get
global
country RU: DFS-UNSET
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5350 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
(5650 - 5850 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR

[-----------------------------------------------------------]

4) As many users are affected by this problem and maintainers don't really
want to revert the problematic patch, is there any other solution to make
AP work again using a clean mainline kernel? Firmware upgrade or any other
solution? What should we do with non-working hardware now?

1. https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain

P.S. sorry, I've resent the message using other MTA, because it wasn't delivered to MLs.

-- 
Best regards,
Andrey Skvortsov

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Brian Norris]

On Sun, Aug 22, 2021 at 9:49 AM Andrey Skvortsov
<andrej.skvortzov@gmail.com> wrote:
> 4) As many users are affected by this problem and maintainers don't really
> want to revert the problematic patch,

I'm not totally sure that's true. So far, it looks like an oversight.

Over a year ago, Kalle said he "just need[ed] to check something
internally first":
https://lore.kernel.org/linux-wireless/87r1rsbdnx.fsf@codeaurora.org/

I don't see the result of that, except that this is marked Superseded:
https://patchwork.kernel.org/project/linux-wireless/patch/20200730124923.271429-1-alsi@bang-olufsen.dk/
and this is marked Rejected:
https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/
I'm not sure if the Rejected was before or after the last reply above...

Maybe it needs an Nth person to submit a revert?

Brian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Andrey Skvortsov]

On 21-08-23 10:23, Brian Norris wrote:
> On Sun, Aug 22, 2021 at 9:49 AM Andrey Skvortsov
> <andrej.skvortzov@gmail.com> wrote:
> > 4) As many users are affected by this problem and maintainers don't really
> > want to revert the problematic patch,
> 
> I'm not totally sure that's true. So far, it looks like an oversight.
> 
> Over a year ago, Kalle said he "just need[ed] to check something
> internally first":
> https://lore.kernel.org/linux-wireless/87r1rsbdnx.fsf@codeaurora.org/
> 
> I don't see the result of that, except that this is marked Superseded:
> https://patchwork.kernel.org/project/linux-wireless/patch/20200730124923.271429-1-alsi@bang-olufsen.dk/
> and this is marked Rejected:
> https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/
> I'm not sure if the Rejected was before or after the last reply above...
> 
> Maybe it needs an Nth person to submit a revert?

Later (Dec 23, 2020) said "Actually I don't see how I could apply the
revert due to the regulatory problems explained by Jouni". [1]
I think this could be the date when your patch was marked as Rejected.

1. http://lists.infradead.org/pipermail/ath10k/2020-December/012370.html

-- 
Best regards,
Andrey Skvortsov

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Brian Norris]

On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
<andrej.skvortzov@gmail.com> wrote:
> On 21-08-23 10:23, Brian Norris wrote:
> > Maybe it needs an Nth person to submit a revert?
>
> Later (Dec 23, 2020) said "Actually I don't see how I could apply the
> revert due to the regulatory problems explained by Jouni". [1]
> I think this could be the date when your patch was marked as Rejected.
>
> 1. http://lists.infradead.org/pipermail/ath10k/2020-December/012370.html

Oh wow, I almost forgot about that... Too many threads. I also forgot
that I already replied, expressing my disagreement:
http://lists.infradead.org/pipermail/ath10k/2020-December/012372.html

But I guess it's not really expected that mainline Linux really works
as-is on most products, unfortunately, and the maintainers don't have
enough time or energy to provide constructive paths forward on real
issues like this :(

Brian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Alvin Šipraga]

On 8/23/21 11:06 PM, Brian Norris wrote:
> On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
> <andrej.skvortzov@gmail.com> wrote:
>> On 21-08-23 10:23, Brian Norris wrote:
>>> Maybe it needs an Nth person to submit a revert?
>>
>> Later (Dec 23, 2020) said "Actually I don't see how I could apply the
>> revert due to the regulatory problems explained by Jouni". [1]
>> I think this could be the date when your patch was marked as Rejected.
>>
>> 1. http://lists.infradead.org/pipermail/ath10k/2020-December/012370.html>> 
> Oh wow, I almost forgot about that... Too many threads. I also forgot
> that I already replied, expressing my disagreement:
> http://lists.infradead.org/pipermail/ath10k/2020-December/012372.html>> 
> But I guess it's not really expected that mainline Linux really works
> as-is on most products, unfortunately, and the maintainers don't have
> enough time or energy to provide constructive paths forward on real
> issues like this :(

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/
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Brian Norris]

On Tue, Aug 24, 2021 at 1:00 AM Alvin Šipraga <ALSI@bang-olufsen.dk> wrote:
> 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]

FYI, my revert was recently merged to Linus's tree and is making its
way into various -stable trees:

https://git.kernel.org/linus/1ec7ed5163c70a0d040150d2279f932c7e7c143f

Side note: it's a small shame that Kalle's scripts seem to have munged
the authorship date -- git thinks it was authored in 2022, when in
fact it was in 2020 ;)

Regards,
Brian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Alvin Šipraga]

Hi Brian,

On Tue, Mar 29, 2022 at 02:06:40PM -0700, Brian Norris wrote:
> On Tue, Aug 24, 2021 at 1:00 AM Alvin Šipraga <ALSI@bang-olufsen.dk> wrote:
> > 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]
> 
> FYI, my revert was recently merged to Linus's tree and is making its
> way into various -stable trees:
> 
> https://git.kernel.org/linus/1ec7ed5163c70a0d040150d2279f932c7e7c143f

That's great news, thanks for sharing the update or else I would have
missed it.

> 
> Side note: it's a small shame that Kalle's scripts seem to have munged
> the authorship date -- git thinks it was authored in 2022, when in
> fact it was in 2020 ;)
> 
> Regards,
> Brian

Kind regards,
Alvin
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Kalle Valo]

Brian Norris <briannorris@chromium.org> writes:

> Side note: it's a small shame that Kalle's scripts seem to have munged
> the authorship date -- git thinks it was authored in 2022, when in
> fact it was in 2020 ;)

Oops, sorry about that. I use stgit and then I edited the commit log to
add the Link tag, it must have changed the date.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Peter Oh]

On 8/22/21 9:49 AM, Andrey Skvortsov wrote:

> 1) Current behaviour maps 0x0 regulatory domain to the most restrictive
> world domain. According to the wiki (probably based on Atheros
> documentation) 0x0 means US. Does wiki contain wrong information?

0x0 means country section in OTP is not written yet and open to set to 
any country.

QCA sets to US in this case as a default value.

> 2) If I understand correctly, 0x0 is always replaced with 0x64 and that
> makes the following code useless, because it will never be executed. Is it
> ok?
>
> drivers/net/wireless/ath/regd.c:703:708
>
> if (reg->country_code == CTRY_DEFAULT &&
>          regdmn == CTRY_DEFAULT) {
>              printk(KERN_DEBUG "ath: EEPROM indicates default "
>                  "country code should be used\n");
>              reg->country_code = CTRY_UNITED_STATES;
> }
I don't think that's true. If you're seeing 0x0 is replaced with 0x64 
(CTRY_BULGARIA = 100), it could be because your device's manufacturer 
preconfigured country code with the value.
> 3) Previously it was possible to get regulatory information using 'iw reg
> get', but now it doesn't work anymore. Is it expected behavior?
>
> [--------------------4.19 ---------------------------------]
> # iw reg get
> global
> country 98: DFS-UNSET
> (2400 - 2483 @ 40), (N/A, 20), (N/A)
> (5150 - 5250 @ 100), (N/A, 20), (N/A), NO-OUTDOOR
> (5250 - 5350 @ 100), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> (5650 - 5730 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> (5730 - 5850 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
> (57240 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
>
>
> [--------------------- 5.10 --------------------------------]
> #iw reg get
> global
> country RU: DFS-UNSET
> (2400 - 2483 @ 40), (N/A, 20), (N/A)
> (5150 - 5350 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> (5650 - 5850 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> (57000 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
>
> [-----------------------------------------------------------]

The 4.19 output tells you that country code is changed to different one 
from manufacturer is set(US).

The 5.10 output seems manufacture set country code to RU. If it's the 
case, No phy level country code looks wrong or a bug.


Thanks,

Peter


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Andrey Skvortsov]

On 21-08-23 11:15, Peter Oh wrote:
> 
> On 8/22/21 9:49 AM, Andrey Skvortsov wrote:
> 
> > 1) Current behaviour maps 0x0 regulatory domain to the most restrictive
> > world domain. According to the wiki (probably based on Atheros
> > documentation) 0x0 means US. Does wiki contain wrong information?
> 
> 0x0 means country section in OTP is not written yet and open to set to any
> country.
> 
> QCA sets to US in this case as a default value.

Do you mean it's set to US by code fragment described below?


> > 2) If I understand correctly, 0x0 is always replaced with 0x64 and that
> > makes the following code useless, because it will never be executed. Is it
> > ok?
> > 
> > drivers/net/wireless/ath/regd.c:703:708
> > 
> > if (reg->country_code == CTRY_DEFAULT &&
> >          regdmn == CTRY_DEFAULT) {
> >              printk(KERN_DEBUG "ath: EEPROM indicates default "
> >                  "country code should be used\n");
> >              reg->country_code = CTRY_UNITED_STATES;
> > }
> I don't think that's true. If you're seeing 0x0 is replaced with 0x64
> (CTRY_BULGARIA = 100), it could be because your device's manufacturer
> preconfigured country code with the value.

0x64 is not BULGARIA, it's not the country code in this case, but regulatory domain - WOR4_WORLD
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/regd_common.h?h=v5.14-rc7#n84

country code is still default (CTRY_DEFAULT == 0x00), but regdmn is
sanitized (set to 0x64) and is not CTRY_DEFAULT (0x00), therefore
country_code is not set to CTRY_UNITED_STATES any more.

> > 3) Previously it was possible to get regulatory information using 'iw reg
> > get', but now it doesn't work anymore. Is it expected behavior?
> > 
> > [--------------------4.19 ---------------------------------]
> > # iw reg get
> > global
> > country 98: DFS-UNSET
> > (2400 - 2483 @ 40), (N/A, 20), (N/A)
> > (5150 - 5250 @ 100), (N/A, 20), (N/A), NO-OUTDOOR
> > (5250 - 5350 @ 100), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> > (5650 - 5730 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> > (5730 - 5850 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
> > (57240 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
> > 
> > 
> > [--------------------- 5.10 --------------------------------]
> > #iw reg get
> > global
> > country RU: DFS-UNSET
> > (2400 - 2483 @ 40), (N/A, 20), (N/A)
> > (5150 - 5350 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> > (5650 - 5850 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> > (57000 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
> > 
> > [-----------------------------------------------------------]
> 
> The 4.19 output tells you that country code is changed to different one from
> manufacturer is set(US).
> 
> The 5.10 output seems manufacture set country code to RU. If it's the case,
> No phy level country code looks wrong or a bug.

There hardware is the same in both cases. RU is displayed just because
I played with 'iw reg set RU/US/..'. My question is more about why on
newer kernels 'iw reg get' doesn't report regulatory information about
these cards (phy#..) any more.

I mean following lines:

phy#0
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

phy#1
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

-- 
Best regards,
Andrey Skvortsov

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Revert: ath: add support for special 0x0 regulatory domain

[Bryce Allen]

To handle my two pcengines routers with Compex cards hit by the 0x0 reg 
domain issue, I created some DKMS packages, one for Debian 11 bullseye 
(5.10) and one for the Ubuntu 20.04 HWE kernel (5.11):

https://github.com/bd4/athregd-dkms

Thanks to sparks71 for an example dkms.conf on how to do this. I just 
copied the drivers/net/wireless/ath directory out of the unpacked 
tarball from distro's linux-source package, removed everything except 
for ath9k/10k which are the cards I have and seem to be affected, and 
updated dkms.conf with desired version and modules.

I am using the module param patch from here:
https://gist.github.com/BigNerd95/0be0a5b52a16524a78fc768f0d208a74

It seems to work, but I still get tainted kernel warnings followed by an 
unpleasant stack dump in dmesg.

Cheers,
Bryce

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k