All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
@ 2020-05-27 16:57 ` Brian Norris
  0 siblings, 0 replies; 40+ messages in thread
From: Brian Norris @ 2020-05-27 16:57 UTC (permalink / raw)
  To: ath10k; +Cc: linux-wireless, linux-kernel, Brian Norris, stable, Wen Gong

This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.

Users are reporting regressions in regulatory domain detection and
channel availability.

The problem this was trying to resolve was fixed in firmware anyway:

    QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042
    https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552

Link: https://bbs.archlinux.org/viewtopic.php?id=254535
Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html
Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html
Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc: <stable@vger.kernel.org>
Cc: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 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.rc0.183.gde8f92d652-goog


^ permalink raw reply	[flat|nested] 40+ messages in thread
* [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
@ 2020-07-30 12:49 ` Alvin Šipraga
  0 siblings, 0 replies; 40+ messages in thread
From: Alvin Šipraga @ 2020-07-30 12:49 UTC (permalink / raw)
  To: ath10k; +Cc: Alvin Šipraga, Wen Gong, Luis R . Rodriguez, linux-wireless

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 <wgong@codeaurora.org>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: linux-wireless@vger.kernel.org
Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
---
 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


^ permalink raw reply	[flat|nested] 40+ messages in thread
* [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
@ 2020-10-22 17:21 Félix Sipma
       [not found] ` <CANe27jKpYm29QOjYOZ_jwHiRxuWx66J+th8-zgbXK4geiCU0_Q@mail.gmail.com>
  0 siblings, 1 reply; 40+ messages in thread
From: Félix Sipma @ 2020-10-22 17:21 UTC (permalink / raw)
  To: ath10k


[-- Attachment #1.1: Type: text/plain, Size: 486 bytes --]

Hello,

Sorry if I break the thread, I'm not subscribed and do not have access 
to the message-id.

I noticed the last message about this issue was on August:
https://lists.infradead.org/pipermail/ath10k/2020-August/011785.html

I got caught by this bug, too. I use a Compex wle900vx (qca988x).

Is there something preventing 
https://patchwork.kernel.org/project/ath10k/patch/20200527165718.129307-1-briannorris@chromium.org/
from being merged?

Regards,

-- 
Félix

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
@ 2020-12-21 12:15 sparks71
  0 siblings, 0 replies; 40+ messages in thread
From: sparks71 @ 2020-12-21 12:15 UTC (permalink / raw)
  To: Alvin Šipraga; +Cc: jkmalinen, felix+kernel, ath10k

> On 10/30/20 8:20 AM, Jouni Malinen wrote:
> > So the issue is in not being able to operate an AP on the 5 GHz band? > That sounds like the expected behavior for any device that has not
> > been calibrated and provisioned for a specific country where >
> regulatory rules allow operation on the 5 GHz band. I understand that
> > this may look like a regression since the commit removed >
> functionality, but it feels like a bug fix to me since that >
> functionality should not have been enabled by default in the first >
> place. The goal here is to avoid inappropriate operation on the band >
> without explicit configuration to enable such operation. In AP >
> devices, the device should have been provisioned for a specific >
> country to be able to enforce the correct frequency range >
> restrictions. The safe default for a device that does not have such >
> explicit configuration within the WLAN component itself is to use the
> > world roaming mode which prevents initialization of radiation (i.e.,
> > does not allow AP mode to be started but allows station mode
> operation > to connect to an already started AP) on the 5 GHz band.
> This explanation makes perfect sense, but are you sure that that is what
> the 0x0 regulatory domain means? For example the pages [1][2] state
> unequivocally that 0x0 means US.
>
> If we assume 0x0 = US, do you agree that an EEPROM programmed with 0x0
> should imply that the device is suitably calibrated for operation in the
> United States, and as such should permit initiating radiation on the 5
> GHz band (etc.)? Or have I missed something?
>
> I also tried to get the patch in question reverted based on this
> rationale, see [3] for more info. I hope somebody can help clear up this
> misunderstanding, since it seems to me that the main issue is: what is
> the true meaning of 0x0?
>
> Btw, the hardware that Félix is referring to does have an FCC ID[4] and
> seems to be suitably certified for the US.
>
> Kind regards,
> Alvin

Hello, this is not correct...

I have such a card with 0x0 in the eeprom
due to the patch the complete midband in station mode is missing
So the card can't see AP's in midband or connect to AP's either....

why are the cards mapped to 0x64 and not 0x6c?

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1895333
https://www.mail-archive.com/ath10k@lists.infradead.org/msg13040.html

the patch has made the card unusable for me and I  had to deal extensively with the thematics ...

and yes my card also has a FCC ID and it would be new to me that there is no midband in the USA...


  best regards


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2022-09-20  5:45 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-27 16:57 [PATCH] Revert "ath: add support for special 0x0 regulatory domain" Brian Norris
2020-05-27 16:57 ` Brian Norris
2020-05-28 12:02 ` Julian Calaby
2020-05-28 12:02   ` Julian Calaby
     [not found]   ` <CAJ-Vmomx0UFEa1w2HsGMQsZb+K8hyK=Zz9cKSo7tHv5GiMc1yw@mail.gmail.com>
2020-06-02 18:35     ` Brian Norris
2020-06-02 18:35       ` Brian Norris
2022-03-07 17:45 ` Kalle Valo
2022-03-07 17:45   ` Kalle Valo
2022-04-23 10:52 ` Patrick Steinhardt
2022-04-23 10:52   ` Patrick Steinhardt
2022-04-25 18:54   ` Brian Norris
2022-04-25 18:54     ` Brian Norris
2022-05-09 18:16     ` Cale Collins
2022-05-09 18:16       ` Cale Collins
2022-05-11 22:52       ` Cale Collins
2022-05-11 22:52         ` Cale Collins
2022-08-30 21:56         ` Brian Norris
2022-08-30 21:56           ` Brian Norris
2022-09-19 17:24           ` Tim Harvey
2022-09-19 17:24             ` Tim Harvey
2022-09-19 23:42             ` Sergey Ryazanov
2022-09-19 23:42               ` Sergey Ryazanov
2022-09-20  5:42               ` Sebastian Gottschall
2022-09-20  5:42                 ` Sebastian Gottschall
2020-07-30 12:49 Alvin Šipraga
2020-07-30 12:49 ` Alvin Šipraga
2020-08-27  7:59 ` Alvin Šipraga
2020-08-27  7:59   ` Alvin Šipraga
2020-08-27 10:12   ` Kalle Valo
2020-08-27 10:12     ` Kalle Valo
2020-08-27 10:25     ` Alvin Šipraga
2020-08-27 10:25       ` Alvin Šipraga
2020-10-22 17:21 Félix Sipma
     [not found] ` <CANe27jKpYm29QOjYOZ_jwHiRxuWx66J+th8-zgbXK4geiCU0_Q@mail.gmail.com>
2020-10-29 14:06   ` Félix Sipma
2020-10-30  7:20     ` Jouni Malinen
2020-10-30  8:51       ` Félix Sipma
2020-12-20  1:32         ` Julian Phillips
2020-10-30 13:23       ` Alvin Sipraga
2020-12-21 13:43         ` sparks71
2020-12-21 12:15 sparks71

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.