This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Per Atheros documentation to manufacturers, the EEPROM regulatory domain
code 0x0 must always map to "US". In particular, it should not map to a
custom world regulatory domain. For references, see [1] and [2] below.
Furthermore, __ath_regd_init() has a specific condition to set the
country code to "US" in this case, which emits the following log
message:
[ 7.814307] ath: EEPROM indicates default country code should be used
The patch being reverted mistakenly maps 0x0 to the custom world
regulatory domain 0x64 - the most restrictive of the world regulatory
domains. The premise of the patch is that in the case of EEPROM
regulatory domain code 0x0, ath_is_world_regd() should return true. But,
as stated above, 0x0 should not map to a world regulatory domain, and so
the function should return false. The original behaviour, whereby
NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
the manufacturer's intent and should not have been changed.
[1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
[2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc: Wen Gong <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: [email protected]
Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
Signed-off-by: Alvin Šipraga <[email protected]>
---
drivers/net/wireless/ath/regd.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index bee9110b91f3..20f4f8ea9f89 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
/*
* Some users have reported their EEPROM programmed with
- * 0x8000 or 0x0 set, this is not a supported regulatory
- * domain but since we have more than one user with it we
- * need a solution for them. We default to 0x64, which is
- * the default Atheros world regulatory domain.
+ * 0x8000 set, this is not a supported regulatory domain
+ * but since we have more than one user with it we need
+ * a solution for them. We default to 0x64, which is the
+ * default Atheros world regulatory domain.
*/
static void ath_regd_sanitize(struct ath_regulatory *reg)
{
- if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
+ if (reg->current_rd != COUNTRY_ERD_FLAG)
return;
printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
reg->current_rd = 0x64;
--
2.27.0
Hi Kalle,
On 7/30/20 2:49 PM, Alvin Šipraga wrote:
> This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
>
> Per Atheros documentation to manufacturers, the EEPROM regulatory domain
> code 0x0 must always map to "US". In particular, it should not map to a
> custom world regulatory domain. For references, see [1] and [2] below.
> Furthermore, __ath_regd_init() has a specific condition to set the
> country code to "US" in this case, which emits the following log
> message:
>
> [ 7.814307] ath: EEPROM indicates default country code should be used
>
> The patch being reverted mistakenly maps 0x0 to the custom world
> regulatory domain 0x64 - the most restrictive of the world regulatory
> domains. The premise of the patch is that in the case of EEPROM
> regulatory domain code 0x0, ath_is_world_regd() should return true. But,
> as stated above, 0x0 should not map to a world regulatory domain, and so
> the function should return false. The original behaviour, whereby
> NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
> the manufacturer's intent and should not have been changed.
>
> [1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
> [2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
>
> Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
> Cc: Wen Gong <[email protected]>
> Cc: Luis R. Rodriguez <[email protected]>
> Cc: [email protected]
> Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
> Signed-off-by: Alvin Šipraga <[email protected]>
> ---
> drivers/net/wireless/ath/regd.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
Do you have any feedback on this patch? No problem if you simply have
not looked yet - I am not sure what kind of lead time to expect on the
list. But without the patch, a (correctly) programmed 0x0 (US) card will
not be able to operate on 5GHz channels without some hacking. I have
cited some references to justify reverting this patch, so I would like
to know if anything further should be done to get this into future kernels?
I wonder also if Wen Gong could comment, whose patch I am reverting in
the first place. Maybe there is something I am missing?
Kind regards,
Alvin
Alvin Šipraga <[email protected]> writes:
> Hi Kalle,
>
> On 7/30/20 2:49 PM, Alvin Šipraga wrote:
>> This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
>>
>> Per Atheros documentation to manufacturers, the EEPROM regulatory domain
>> code 0x0 must always map to "US". In particular, it should not map to a
>> custom world regulatory domain. For references, see [1] and [2] below.
>> Furthermore, __ath_regd_init() has a specific condition to set the
>> country code to "US" in this case, which emits the following log
>> message:
>>
>> [ 7.814307] ath: EEPROM indicates default country code should be used
>>
>> The patch being reverted mistakenly maps 0x0 to the custom world
>> regulatory domain 0x64 - the most restrictive of the world regulatory
>> domains. The premise of the patch is that in the case of EEPROM
>> regulatory domain code 0x0, ath_is_world_regd() should return true. But,
>> as stated above, 0x0 should not map to a world regulatory domain, and so
>> the function should return false. The original behaviour, whereby
>> NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
>> the manufacturer's intent and should not have been changed.
>>
>> [1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
>> [2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
>>
>> Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
>> Cc: Wen Gong <[email protected]>
>> Cc: Luis R. Rodriguez <[email protected]>
>> Cc: [email protected]
>> Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
>> Signed-off-by: Alvin Šipraga <[email protected]>
>> ---
>> drivers/net/wireless/ath/regd.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> Do you have any feedback on this patch? No problem if you simply have
> not looked yet - I am not sure what kind of lead time to expect on the
> list. But without the patch, a (correctly) programmed 0x0 (US) card
> will not be able to operate on 5GHz channels without some hacking. I
> have cited some references to justify reverting this patch, so I would
> like to know if anything further should be done to get this into
> future kernels?
>
> I wonder also if Wen Gong could comment, whose patch I am reverting in
> the first place. Maybe there is something I am missing?
I'm working on it, I just need to check something internally first.
BTW, Brian submitted an identical revert first so I'm planning to use
his patch instead of yours:
https://patchwork.kernel.org/patch/11573585/
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 8/27/20 12:12 PM, Kalle Valo wrote:
> Alvin Šipraga <[email protected]> writes:
>
>> Hi Kalle,
>>
>> On 7/30/20 2:49 PM, Alvin Šipraga wrote:
>>> This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
>>>
>>> Per Atheros documentation to manufacturers, the EEPROM regulatory domain
>>> code 0x0 must always map to "US". In particular, it should not map to a
>>> custom world regulatory domain. For references, see [1] and [2] below.
>>> Furthermore, __ath_regd_init() has a specific condition to set the
>>> country code to "US" in this case, which emits the following log
>>> message:
>>>
>>> [ 7.814307] ath: EEPROM indicates default country code should be used
>>>
>>> The patch being reverted mistakenly maps 0x0 to the custom world
>>> regulatory domain 0x64 - the most restrictive of the world regulatory
>>> domains. The premise of the patch is that in the case of EEPROM
>>> regulatory domain code 0x0, ath_is_world_regd() should return true. But,
>>> as stated above, 0x0 should not map to a world regulatory domain, and so
>>> the function should return false. The original behaviour, whereby
>>> NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
>>> the manufacturer's intent and should not have been changed.
>>>
>>> [1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
>>> [2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
>>>
>>> Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
>>> Cc: Wen Gong <[email protected]>
>>> Cc: Luis R. Rodriguez <[email protected]>
>>> Cc: [email protected]
>>> Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
>>> Signed-off-by: Alvin Šipraga <[email protected]>
>>> ---
>>> drivers/net/wireless/ath/regd.c | 10 +++++-----
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> Do you have any feedback on this patch? No problem if you simply have
>> not looked yet - I am not sure what kind of lead time to expect on the
>> list. But without the patch, a (correctly) programmed 0x0 (US) card
>> will not be able to operate on 5GHz channels without some hacking. I
>> have cited some references to justify reverting this patch, so I would
>> like to know if anything further should be done to get this into
>> future kernels?
>>
>> I wonder also if Wen Gong could comment, whose patch I am reverting in
>> the first place. Maybe there is something I am missing?
>
> I'm working on it, I just need to check something internally first.
>
> BTW, Brian submitted an identical revert first so I'm planning to use
> his patch instead of yours:
>
> https://patchwork.kernel.org/patch/11573585/
Hi Kalle,
Thank you for the update, glad to hear it. Sorry that I did not notice
Brian's patch - I guess you can close my one on patchwork then.
Kind regards,
Alvin
Hello Brian and Kalle,
I'm experiencing an issue very similar to this. The regulatory domain
settings wouldn't allow me to create an AP on 5ghz bands on kernels
newer than 5.10 when using a WLE900VX (QCA9984) radio. I bisected the
kernel and ultimately landed on the regression that Brian patched. I
applied the patch and that resolved the issue from 5.4 up to 5.10.
For versions later than that I encountered the same problem. I tried
to bisect again but PCI is broken for the ARM board(s) I'm using in
many of the RC's, I'm pretty new to all of this and it was just over
my head. I saw Kalle pushed Brian's patch a few weeks ago, so I
figured the politics behind how the regulatory domain should be
addressed was decided at that point. I cherry picked Brian's patch
onto 5.17 to test, the results are below. Can someone help me figure
out what I can do to get 5ghz APs back?
If there's any more information I can provide please let me know, I
wanted to keep things on the shorter side.
cale@cale:~/builds/upstream/linux$ git log --oneline
5c12efe9e783 (HEAD) Revert "ath: add support for special 0x0 regulatory domain"
f443e374ae13 (tag: v5.17) Linux 5.17
#On my ARM64 board
root@focal-ventana:~# uname -a
Linux focal-ventana 5.17.0-00001-g5c12efe9e783 #1 SMP Wed Apr 6
16:33:54 PDT 2022 armv7l armv7l armv7l GNU/Linux
root@focal-ventana:~# ls /sys/class/net/
can0 eth0 lo sit0 wlp6s0
root@focal-ventana:~# iw phy phy0 info | grep " MHz \[" | grep -v "no
IR\|disabled"
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
root@focal-ventana:~# iw reg get
global
country 00: DFS-UNSET
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
(5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
phy#0
country 99: DFS-UNSET
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
(5715 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
#dmesg |grep ath output
[ 5.724215] ath10k_pci 0000:06:00.0: enabling device (0140 -> 0142)
[ 5.732439] ath10k_pci 0000:06:00.0: pci irq msi oper_irq_mode
2 irq_mode 0 reset_mode 0
[ 17.573591] ath10k_pci 0000:06:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043202ff sub 0000:0000
[ 17.573707] ath10k_pci 0000:06:00.0: kconfig debug 0 debugfs 0
tracing 0 dfs 0 testmode 0
[ 17.575118] ath10k_pci 0000:06:00.0: firmware ver
10.2.4-1.0-00047 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast
crc32 35bd9258
[ 17.637397] ath10k_pci 0000:06:00.0: board_file api 1 bmi_id
N/A crc32 bebc7c08
[ 18.849651] ath10k_pci 0000:06:00.0: htt-ver 2.1 wmi-op 5
htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
Best regards,
Cale Collins
Cale Collins
Field Applications Engineer II
Gateworks Corporation
(805)781-2000 x37
3026 S. Higuera, San Luis Obispo, CA 93401
http://www.gateworks.com
On Mon, Apr 25, 2022 at 11:55 AM Brian Norris <[email protected]> wrote:
>
> Hi Patrick,
>
> On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <[email protected]> wrote:
> > This revert is in fact causing problems on my machine. I have a QCA9984,
> > which exports two network interfaces. While I was able to still use one
> > of both NICs for 2.4GHz, I couldn't really use the other card to set up
> > a 5GHz AP anymore because all frequencies were restricted. This has
> > started with v5.17.1, to which this revert was backported.
> >
> > Reverting this patch again fixes the issue on my system. So it seems
> > like there still are cards out there in the wild which have a value of
> > 0x0 as their regulatory domain.
> >
> > Quoting from your other mail:
> >
> > > My understanding was that no QCA modules *should* be shipped with a
> > > value of 0 in this field. The instance I'm aware of was more or less a
> > > manufacturing error I think, and we got Qualcomm to patch it over in
> > > software.
> >
> > This sounds like the issue should've already been fixed in firmware,
> > right?
>
> See the original patch:
> https://git.kernel.org/linus/2dc016599cfa9672a147528ca26d70c3654a5423
>
> "Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029."
>
> That patch was only tested for QCA6174 SDIO, and the 6174 firmware has
> since been updated. So none of that really applies to QCA9984. I
> suppose your device was also not working before v5.6 either, and IIUC,
> according to Qualcomm your hardware is a manufacturing error (i.e.,
> invalid country code).
>
> I don't know what to tell you exactly, other than that the original
> patch was wrong/unnecessary (and broke various existing systems) so it
> should be reverted. I'm not quite sure how to fix the variety of
> hardware out there (like yours) that may be using non-conforming
> EEPROM settings. It would seem to me that we might need some more
> targeted way of addressing broken hardware, rather than changing this
> particular default workaround. I'm honestly not that familiar with
> this Qualcomm regulatory stuff though, so my main contribution was
> just to suggest reverting (i.e., don't break what used to work); I'm
> not as savvy on providing alternative "fixes" for you.
>
> (That said: I *think* what's happening is that in the absence of a
> proper EEPROM code, ath drivers fall back to a default=US country
> code, and without further information to know you're compliant,
> regulatory rules disallow initiating radiation (such as, an AP) on
> 5GHz.)
>
> > I've added the relevant dmesg
> > snippets though in case I'm mistaken:
>
> With what kernel? That looks like pre-v5.17.1. The "broken"
> (post-5.17.1) logs might be a bit more informative.
>
> Sorry,
> Brian
Adding Kalle, I got his address wrong the first time.
On Mon, May 9, 2022 at 11:16 AM Cale Collins <[email protected]> wrote:
>
> Hello Brian and Kalle,
>
> I'm experiencing an issue very similar to this. The regulatory domain
> settings wouldn't allow me to create an AP on 5ghz bands on kernels
> newer than 5.10 when using a WLE900VX (QCA9984) radio. I bisected the
> kernel and ultimately landed on the regression that Brian patched. I
> applied the patch and that resolved the issue from 5.4 up to 5.10.
> For versions later than that I encountered the same problem. I tried
> to bisect again but PCI is broken for the ARM board(s) I'm using in
> many of the RC's, I'm pretty new to all of this and it was just over
> my head. I saw Kalle pushed Brian's patch a few weeks ago, so I
> figured the politics behind how the regulatory domain should be
> addressed was decided at that point. I cherry picked Brian's patch
> onto 5.17 to test, the results are below. Can someone help me figure
> out what I can do to get 5ghz APs back?
>
> If there's any more information I can provide please let me know, I
> wanted to keep things on the shorter side.
>
> cale@cale:~/builds/upstream/linux$ git log --oneline
> 5c12efe9e783 (HEAD) Revert "ath: add support for special 0x0 regulatory domain"
> f443e374ae13 (tag: v5.17) Linux 5.17
>
> #On my ARM64 board
>
> root@focal-ventana:~# uname -a
> Linux focal-ventana 5.17.0-00001-g5c12efe9e783 #1 SMP Wed Apr 6
> 16:33:54 PDT 2022 armv7l armv7l armv7l GNU/Linux
>
>
> root@focal-ventana:~# ls /sys/class/net/
> can0 eth0 lo sit0 wlp6s0
>
> root@focal-ventana:~# iw phy phy0 info | grep " MHz \[" | grep -v "no
> IR\|disabled"
> * 2412 MHz [1] (20.0 dBm)
> * 2417 MHz [2] (20.0 dBm)
> * 2422 MHz [3] (20.0 dBm)
> * 2427 MHz [4] (20.0 dBm)
> * 2432 MHz [5] (20.0 dBm)
> * 2437 MHz [6] (20.0 dBm)
> * 2442 MHz [7] (20.0 dBm)
> * 2447 MHz [8] (20.0 dBm)
> * 2452 MHz [9] (20.0 dBm)
> * 2457 MHz [10] (20.0 dBm)
> * 2462 MHz [11] (20.0 dBm)
>
>
> root@focal-ventana:~# iw reg get
> global
> country 00: DFS-UNSET
> (2402 - 2472 @ 40), (N/A, 20), (N/A)
> (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR
> (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR
> (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> (57240 - 63720 @ 2160), (N/A, 0), (N/A)
>
> phy#0
> country 99: DFS-UNSET
> (2402 - 2472 @ 40), (N/A, 20), (N/A)
> (5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
> (5715 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
>
> #dmesg |grep ath output
>
> [ 5.724215] ath10k_pci 0000:06:00.0: enabling device (0140 -> 0142)
> [ 5.732439] ath10k_pci 0000:06:00.0: pci irq msi oper_irq_mode
> 2 irq_mode 0 reset_mode 0
> [ 17.573591] ath10k_pci 0000:06:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 17.573707] ath10k_pci 0000:06:00.0: kconfig debug 0 debugfs 0
> tracing 0 dfs 0 testmode 0
> [ 17.575118] ath10k_pci 0000:06:00.0: firmware ver
> 10.2.4-1.0-00047 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast
> crc32 35bd9258
> [ 17.637397] ath10k_pci 0000:06:00.0: board_file api 1 bmi_id
> N/A crc32 bebc7c08
> [ 18.849651] ath10k_pci 0000:06:00.0: htt-ver 2.1 wmi-op 5
> htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
>
> Best regards,
>
> Cale Collins
>
>
> Cale Collins
> Field Applications Engineer II
> Gateworks Corporation
> (805)781-2000 x37
> 3026 S. Higuera, San Luis Obispo, CA 93401
> http://www.gateworks.com
>
>
>
> On Mon, Apr 25, 2022 at 11:55 AM Brian Norris <[email protected]> wrote:
> >
> > Hi Patrick,
> >
> > On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <[email protected]> wrote:
> > > This revert is in fact causing problems on my machine. I have a QCA9984,
> > > which exports two network interfaces. While I was able to still use one
> > > of both NICs for 2.4GHz, I couldn't really use the other card to set up
> > > a 5GHz AP anymore because all frequencies were restricted. This has
> > > started with v5.17.1, to which this revert was backported.
> > >
> > > Reverting this patch again fixes the issue on my system. So it seems
> > > like there still are cards out there in the wild which have a value of
> > > 0x0 as their regulatory domain.
> > >
> > > Quoting from your other mail:
> > >
> > > > My understanding was that no QCA modules *should* be shipped with a
> > > > value of 0 in this field. The instance I'm aware of was more or less a
> > > > manufacturing error I think, and we got Qualcomm to patch it over in
> > > > software.
> > >
> > > This sounds like the issue should've already been fixed in firmware,
> > > right?
> >
> > See the original patch:
> > https://git.kernel.org/linus/2dc016599cfa9672a147528ca26d70c3654a5423
> >
> > "Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029."
> >
> > That patch was only tested for QCA6174 SDIO, and the 6174 firmware has
> > since been updated. So none of that really applies to QCA9984. I
> > suppose your device was also not working before v5.6 either, and IIUC,
> > according to Qualcomm your hardware is a manufacturing error (i.e.,
> > invalid country code).
> >
> > I don't know what to tell you exactly, other than that the original
> > patch was wrong/unnecessary (and broke various existing systems) so it
> > should be reverted. I'm not quite sure how to fix the variety of
> > hardware out there (like yours) that may be using non-conforming
> > EEPROM settings. It would seem to me that we might need some more
> > targeted way of addressing broken hardware, rather than changing this
> > particular default workaround. I'm honestly not that familiar with
> > this Qualcomm regulatory stuff though, so my main contribution was
> > just to suggest reverting (i.e., don't break what used to work); I'm
> > not as savvy on providing alternative "fixes" for you.
> >
> > (That said: I *think* what's happening is that in the absence of a
> > proper EEPROM code, ath drivers fall back to a default=US country
> > code, and without further information to know you're compliant,
> > regulatory rules disallow initiating radiation (such as, an AP) on
> > 5GHz.)
> >
> > > I've added the relevant dmesg
> > > snippets though in case I'm mistaken:
> >
> > With what kernel? That looks like pre-v5.17.1. The "broken"
> > (post-5.17.1) logs might be a bit more informative.
> >
> > Sorry,
> > Brian
On Tue, Aug 30, 2022 at 2:57 PM Brian Norris <[email protected]> wrote:
>
> Hi Cale,
>
> I meant to respond a while back, but didn't get around to it, sorry.
> In case it's still helpful:
>
> On Wed, May 11, 2022 at 3:52 PM Cale Collins <[email protected]> wrote:
> > On Mon, May 9, 2022 at 11:16 AM Cale Collins <[email protected]> wrote:
> > > I'm experiencing an issue very similar to this. The regulatory domain
> > > settings wouldn't allow me to create an AP on 5ghz bands on kernels
> > > newer than 5.10 when using a WLE900VX (QCA9984) radio. I bisected the
> > > kernel and ultimately landed on the regression that Brian patched.
>
> If the revert broke you, then you were also broken before v5.6. This
> patch only landed in v5.6-rc1:
>
> 2dc016599cfa ath: add support for special 0x0 regulatory domain
>
> I'm not really an expert on the wide variety of ath-related hardware
> production, but given the many people complaining about the existence
> of the non-reverted patch, it seemed like a revert was the best way
> forward -- don't break those that weren't already broken pre-5.6.
>
> > > root@focal-ventana:~# iw reg get
> > > global
> > > country 00: DFS-UNSET
> > > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > > (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR
> > > (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
> > > (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR
> > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR
> > > (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> > > (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> > > (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> > >
> > > phy#0
> > > country 99: DFS-UNSET
> > > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > > (5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
> > > (5715 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
>
> Unless there's some other bug hidden in here in how we're reading
> EEPROM settings, it sounds like you have a badly-provisioned PCI
> module, with no EEPROM country code. Thus, the driver has to
> conservatively treat you as a very-limited "world roaming" regulatory
> class, which mostly disables 5GHz, or at least doesn't let you
> initiate much radiation on your own (which basically eliminates AP
> mode).
>
> The "fix" there would be to get a different, correctly-provisioned
> (for your regulatory domain) module.
>
> Also, I didn't notice until today: technically, you also could be
> retrieving your incorrect country code info from ACPI; but if you're
> using a typical ARM board like claimed, it's unlikely you're using
> ACPI.
>
> Somewhat of a sidetrack: The existence of ACPI override support does
> suggest that perhaps there's some room for a Device Tree property, so
> one can set their regulatory domain on a per-board basis. I've
> definitely known some downstream product makers use that sort of
> approach -- and that very "solution" is potentially why some devices
> don't get a valid EEPROM (if the manufacturer could hack the drivers,
> why bother getting the EEPROM right?), and therefore don't work
> correctly with upstream kernels... Unfortunately, that kind of
> solution is hard to deploy 100% correctly for upstream Linux, because
> the Device Tree would need to change depending on which country the
> affected system is shipped to. It's easier to get those things right
> in a pre-flashed firmware or an EEPROM; it's harder to get those in a
> software DTS file shipped to everyone in the mainline kernel sources.
>
> > > #dmesg |grep ath output
>
> In the slim chance there's something else going on in the driver, you
> might try to capture logs with ATH10K_DBG_BOOT and
> ATH10K_DBG_REGULATORY logging enabled. That could look something like:
>
> echo 0x820 > /sys/module/ath10k_core/parameters/debug_mask
> rmmod ath10k_pci
> modprobe ath10k_pci
> dmesg | grep ath
>
Brian,
Thanks for the follow-up. Indeed the situation Cale had here was with
Compex WLE900VX which apparently does have what we now understand to
be an unprogrammed EEPROM. I suspect this was some choice from Compex
that somehow must have benefited them at the time and I'm not clear if
there are many other cards that have this same issue. Maybe something
should be added to the ath drivers wiki pages
(https://wireless.wiki.kernel.org/en/users/drivers/ath9k)
Reverting commit 2dc016599cfa ("ath: add support for special 0x0
regulatory domain") does indeed resolve the issue on the older kernels
but somehow the issue creeps back in with later kernels (definitely
appears in 5.15) perhaps due to other changes. Perhaps you can confirm
my findings if you have a card like this.
For 5.15 and newer I've elected to add a hack from OpenWrt for the
kernel's used to support my companies boards which adds a kernel
config to not enforce EEPROM reg restrictions for the kernels that our
users use:
https://github.com/Gateworks/linux-venice/commit/39ef369cbca269fa32e8f85d31ae813b97d84aec
Best Regards,
Tim
Hello,
I would like to add my 2c.
On Mon, Sep 19, 2022 at 8:25 PM Tim Harvey <[email protected]> wrote:
> I'm not clear if
> there are many other cards that have this same issue.
The list of cards with unprogrammed regdomain can be extended with
several relatively modern models:
* MikroTik R11e-5HacD (QCA9882 based)
* MikroTik R11e-5HacT (QCA9880 based)
* QNAP QWA-AC2600 (QCA9984 based) [1]
As you can see these are powerful and massive cards for WISPs. Or at
least to run as an AP. I also know a bunch of .11a/b/g/n cards with
zero regdomain and the same target audience. Except maybe for the
legacy Wistorn CM9, which is a relatively compact card.
Also, a huge number of wireless routers and access points have
unprogrammed regdomain. But probably this is not the case, since they
anyway can not run a stock kernel.
1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1895333
--
Sergey
Am 20.09.2022 um 01:42 schrieb Sergey Ryazanov:
> Hello,
>
> I would like to add my 2c.
>
> On Mon, Sep 19, 2022 at 8:25 PM Tim Harvey <[email protected]> wrote:
>> I'm not clear if
>> there are many other cards that have this same issue.
> The list of cards with unprogrammed regdomain can be extended with
> several relatively modern models:
> * MikroTik R11e-5HacD (QCA9882 based)
> * MikroTik R11e-5HacT (QCA9880 based)
> * QNAP QWA-AC2600 (QCA9984 based) [1]
>
> As you can see these are powerful and massive cards for WISPs. Or at
> least to run as an AP. I also know a bunch of .11a/b/g/n cards with
> zero regdomain and the same target audience. Except maybe for the
> legacy Wistorn CM9, which is a relatively compact card.
>
> Also, a huge number of wireless routers and access points have
> unprogrammed regdomain. But probably this is not the case, since they
> anyway can not run a stock kernel.
>
> 1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1895333
let me add my 2c. the regdomain 0 is very common and defacto a standard
for all non oem cards on the market. i have only seen real programmed cards
as buildin cards in laptops.
beside of these zero cards there are other special regdomains available
for ath cards
>