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
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
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
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?
quoted
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.
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
From: Brian Norris <briannorris@chromium.org> Date: 2021-08-23 21:06:56
On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
[off-list ref] wrote:
On 21-08-23 10:23, Brian Norris wrote:
quoted
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
On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
[off-list ref] wrote:
quoted
On 21-08-23 10:23, Brian Norris wrote:
quoted
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/
From: Brian Norris <briannorris@chromium.org> Date: 2022-03-29 21:07:00
On Tue, Aug 24, 2021 at 1:00 AM Alvin Šipraga [off-list ref] 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
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 [off-list ref] wrote:
quoted
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]
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
From: Kalle Valo <kvalo@kernel.org> Date: 2022-03-30 05:35:47
Brian Norris [off-list ref] 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 ;)