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

[Andrey Skvortsov <andrej.skvortzov@gmail.com>]

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