* Revert: ath: add support for special 0x0 regulatory domain @ 2021-08-22 16:49 Andrey Skvortsov 2021-08-23 17:23 ` Brian Norris 2021-08-23 18:15 ` Peter Oh 0 siblings, 2 replies; 10+ messages in thread From: Andrey Skvortsov @ 2021-08-22 16:49 UTC (permalink / raw) To: linux-wireless, ath10k Cc: Wen Gong, Kalle Valo, Alvin Šipraga, Brian Norris, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-22 16:49 Revert: ath: add support for special 0x0 regulatory domain Andrey Skvortsov @ 2021-08-23 17:23 ` Brian Norris 2021-08-23 20:19 ` Andrey Skvortsov 2021-08-23 18:15 ` Peter Oh 1 sibling, 1 reply; 10+ messages in thread From: Brian Norris @ 2021-08-23 17:23 UTC (permalink / raw) To: Andrey Skvortsov Cc: linux-wireless, ath10k, Wen Gong, Kalle Valo, Alvin Šipraga, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-23 17:23 ` Brian Norris @ 2021-08-23 20:19 ` Andrey Skvortsov 2021-08-23 21:06 ` Brian Norris 0 siblings, 1 reply; 10+ messages in thread From: Andrey Skvortsov @ 2021-08-23 20:19 UTC (permalink / raw) To: Brian Norris Cc: linux-wireless, ath10k, Wen Gong, Kalle Valo, Alvin Šipraga, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-23 20:19 ` Andrey Skvortsov @ 2021-08-23 21:06 ` Brian Norris 2021-08-24 8:00 ` Alvin Šipraga 0 siblings, 1 reply; 10+ messages in thread From: Brian Norris @ 2021-08-23 21:06 UTC (permalink / raw) To: Andrey Skvortsov Cc: linux-wireless, ath10k, Wen Gong, Kalle Valo, Alvin Šipraga, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-23 21:06 ` Brian Norris @ 2021-08-24 8:00 ` Alvin Šipraga 2022-03-29 21:06 ` Brian Norris 0 siblings, 1 reply; 10+ messages in thread From: Alvin Šipraga @ 2021-08-24 8:00 UTC (permalink / raw) To: Brian Norris, Andrey Skvortsov Cc: linux-wireless, ath10k, Wen Gong, Kalle Valo, Julian Calaby, svp, felix+debian, Massimo Maggi 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/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-24 8:00 ` Alvin Šipraga @ 2022-03-29 21:06 ` Brian Norris 2022-03-29 21:21 ` Alvin Šipraga 2022-03-30 5:35 ` Kalle Valo 0 siblings, 2 replies; 10+ messages in thread From: Brian Norris @ 2022-03-29 21:06 UTC (permalink / raw) To: Alvin Šipraga Cc: Andrey Skvortsov, linux-wireless, ath10k, Wen Gong, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2022-03-29 21:06 ` Brian Norris @ 2022-03-29 21:21 ` Alvin Šipraga 2022-03-30 5:35 ` Kalle Valo 1 sibling, 0 replies; 10+ messages in thread From: Alvin Šipraga @ 2022-03-29 21:21 UTC (permalink / raw) To: Brian Norris Cc: Andrey Skvortsov, linux-wireless, ath10k, Wen Gong, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2022-03-29 21:06 ` Brian Norris 2022-03-29 21:21 ` Alvin Šipraga @ 2022-03-30 5:35 ` Kalle Valo 1 sibling, 0 replies; 10+ messages in thread From: Kalle Valo @ 2022-03-30 5:35 UTC (permalink / raw) To: Brian Norris Cc: ALSI, Andrey Skvortsov, linux-wireless, ath10k, Julian Calaby, svp, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-22 16:49 Revert: ath: add support for special 0x0 regulatory domain Andrey Skvortsov 2021-08-23 17:23 ` Brian Norris @ 2021-08-23 18:15 ` Peter Oh 2021-08-23 20:39 ` Andrey Skvortsov 1 sibling, 1 reply; 10+ messages in thread From: Peter Oh @ 2021-08-23 18:15 UTC (permalink / raw) To: Andrey Skvortsov, linux-wireless, ath10k Cc: Wen Gong, Kalle Valo, Alvin Šipraga, Brian Norris, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Revert: ath: add support for special 0x0 regulatory domain 2021-08-23 18:15 ` Peter Oh @ 2021-08-23 20:39 ` Andrey Skvortsov 0 siblings, 0 replies; 10+ messages in thread From: Andrey Skvortsov @ 2021-08-23 20:39 UTC (permalink / raw) To: Peter Oh Cc: linux-wireless, ath10k, Wen Gong, Kalle Valo, Alvin Šipraga, Brian Norris, Julian Calaby, svp, felix+debian, Massimo Maggi 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-03-30 5:35 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-22 16:49 Revert: ath: add support for special 0x0 regulatory domain Andrey Skvortsov 2021-08-23 17:23 ` Brian Norris 2021-08-23 20:19 ` Andrey Skvortsov 2021-08-23 21:06 ` Brian Norris 2021-08-24 8:00 ` Alvin Šipraga 2022-03-29 21:06 ` Brian Norris 2022-03-29 21:21 ` Alvin Šipraga 2022-03-30 5:35 ` Kalle Valo 2021-08-23 18:15 ` Peter Oh 2021-08-23 20:39 ` Andrey Skvortsov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).