Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 22 Aug 2021 19:49:02 +0300
From:   Andrey Skvortsov <andrej.skvortzov@gmail.com>
To:     linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Cc:     Wen Gong <wgong@codeaurora.org>, Kalle Valo <kvalo@codeaurora.org>,
        Alvin =?utf-8?Q?=C5=A0ipraga?= <alsi@bang-olufsen.dk>,
        Brian Norris <briannorris@chromium.org>,
        Julian Calaby <julian.calaby@gmail.com>, svp <svpm@yandex.ru>,
        felix+debian@gueux.org, Massimo Maggi <me@massimo-maggi.eu>
Subject: Revert: ath: add support for special 0x0 regulatory domain
Message-ID: <YSJ//ki/A1EgfLga@skv.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Precedence: bulk

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