* [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 related [flat|nested] 40+ messages in thread
* [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: Brian Norris, linux-wireless, linux-kernel, 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" 2020-05-27 16:57 ` Brian Norris @ 2020-05-28 12:02 ` Julian Calaby -1 siblings, 0 replies; 40+ messages in thread From: Julian Calaby @ 2020-05-28 12:02 UTC (permalink / raw) To: Brian Norris; +Cc: ath10k, linux-wireless, LKML, stable, Wen Gong Hi Brian, On Thu, May 28, 2020 at 5:18 AM Brian Norris <briannorris@chromium.org> wrote: > > 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: Should we tell the user their firmware needs to be upgraded if it reports this regulatory domain instead of completely dropping support for it? Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2020-05-28 12:02 ` Julian Calaby 0 siblings, 0 replies; 40+ messages in thread From: Julian Calaby @ 2020-05-28 12:02 UTC (permalink / raw) To: Brian Norris; +Cc: stable, linux-wireless, LKML, ath10k, Wen Gong Hi Brian, On Thu, May 28, 2020 at 5:18 AM Brian Norris <briannorris@chromium.org> wrote: > > 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: Should we tell the user their firmware needs to be upgraded if it reports this regulatory domain instead of completely dropping support for it? Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <CAJ-Vmomx0UFEa1w2HsGMQsZb+K8hyK=Zz9cKSo7tHv5GiMc1yw@mail.gmail.com>]
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" [not found] ` <CAJ-Vmomx0UFEa1w2HsGMQsZb+K8hyK=Zz9cKSo7tHv5GiMc1yw@mail.gmail.com> @ 2020-06-02 18:35 ` Brian Norris 0 siblings, 0 replies; 40+ messages in thread From: Brian Norris @ 2020-06-02 18:35 UTC (permalink / raw) To: Adrian Chadd Cc: Julian Calaby, ath10k, linux-wireless, LKML, stable, Wen Gong On Thu, May 28, 2020 at 8:42 AM Adrian Chadd <adrian@freebsd.org> wrote: > On Thu, 28 May 2020 at 05:02, Julian Calaby <julian.calaby@gmail.com> wrote: > > On Thu, May 28, 2020 at 5:18 AM Brian Norris <briannorris@chromium.org> wrote: > > > > > > 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: > > > > Should we tell the user their firmware needs to be upgraded if it > > reports this regulatory domain instead of completely dropping support > > for it? I'm not really sure how to do that properly in general, and I don't plan to do so. I'm simply reverting a change that caused people problems, and noting at the same time that the original problem was resolved differently. I don't really have a stake in this patch, because everything I care about works correctly either way. (And AFAICT, any hardware that is affected by this patch is somewhat broken.) I'm only posting the revert as a community service, because Wen couldn't be bothered to do it himself. > Also that commit mentioned a 6174 firmware, but what about all the other older chips with a regulatory domain of 0x0 ? 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. I don't think people expected anybody else to have shipped modules with a 0 value, but apparently they did. I don't know what to do with those, other than just leave well enough alone (i.e., $subject revert). > As a side note, I'd /really appreciate/ if ath10k changes were tested on a variety of ath10k hardware and firmware revisions, rather than just either the Rome or embedded radios, rather than also including peregrine, cascade, besra, etc. Wouldn't we all love it if everybody else tested appropriately. But Qualcomm folks can't be coordinated (trust me, I've tried), and apart from things like KernelCI (which so far has no WiFi tests, IIUC), there's no community testing efforts that don't involve "${RANDOM_PERSON} boots ${PERSONAL_BOX} and see if it blows up." This also might not be the best place to admit it, but I'll be up front: I have no idea what peregrine, cascade, or besra are. Brian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2020-06-02 18:35 ` Brian Norris 0 siblings, 0 replies; 40+ messages in thread From: Brian Norris @ 2020-06-02 18:35 UTC (permalink / raw) To: Adrian Chadd Cc: Julian Calaby, linux-wireless, LKML, stable, ath10k, Wen Gong On Thu, May 28, 2020 at 8:42 AM Adrian Chadd <adrian@freebsd.org> wrote: > On Thu, 28 May 2020 at 05:02, Julian Calaby <julian.calaby@gmail.com> wrote: > > On Thu, May 28, 2020 at 5:18 AM Brian Norris <briannorris@chromium.org> wrote: > > > > > > 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: > > > > Should we tell the user their firmware needs to be upgraded if it > > reports this regulatory domain instead of completely dropping support > > for it? I'm not really sure how to do that properly in general, and I don't plan to do so. I'm simply reverting a change that caused people problems, and noting at the same time that the original problem was resolved differently. I don't really have a stake in this patch, because everything I care about works correctly either way. (And AFAICT, any hardware that is affected by this patch is somewhat broken.) I'm only posting the revert as a community service, because Wen couldn't be bothered to do it himself. > Also that commit mentioned a 6174 firmware, but what about all the other older chips with a regulatory domain of 0x0 ? 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. I don't think people expected anybody else to have shipped modules with a 0 value, but apparently they did. I don't know what to do with those, other than just leave well enough alone (i.e., $subject revert). > As a side note, I'd /really appreciate/ if ath10k changes were tested on a variety of ath10k hardware and firmware revisions, rather than just either the Rome or embedded radios, rather than also including peregrine, cascade, besra, etc. Wouldn't we all love it if everybody else tested appropriately. But Qualcomm folks can't be coordinated (trust me, I've tried), and apart from things like KernelCI (which so far has no WiFi tests, IIUC), there's no community testing efforts that don't involve "${RANDOM_PERSON} boots ${PERSONAL_BOX} and see if it blows up." This also might not be the best place to admit it, but I'll be up front: I have no idea what peregrine, cascade, or besra are. Brian _______________________________________________ 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-05-27 16:57 ` Brian Norris @ 2022-03-07 17:45 ` Kalle Valo -1 siblings, 0 replies; 40+ messages in thread From: Kalle Valo @ 2022-03-07 17:45 UTC (permalink / raw) To: Brian Norris Cc: ath10k, linux-wireless, linux-kernel, Brian Norris, stable, Wen Gong Brian Norris <briannorris@chromium.org> wrote: > 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 > Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/ > 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> > Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Patch applied to ath-next branch of ath.git, thanks. 1ec7ed5163c7 Revert "ath: add support for special 0x0 regulatory domain" -- https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-03-07 17:45 ` Kalle Valo 0 siblings, 0 replies; 40+ messages in thread From: Kalle Valo @ 2022-03-07 17:45 UTC (permalink / raw) To: Brian Norris Cc: ath10k, linux-wireless, linux-kernel, Brian Norris, stable, Wen Gong Brian Norris <briannorris@chromium.org> wrote: > 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 > Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/ > 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> > Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Patch applied to ath-next branch of ath.git, thanks. 1ec7ed5163c7 Revert "ath: add support for special 0x0 regulatory domain" -- https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches _______________________________________________ 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-05-27 16:57 ` Brian Norris @ 2022-04-23 10:52 ` Patrick Steinhardt -1 siblings, 0 replies; 40+ messages in thread From: Patrick Steinhardt @ 2022-04-23 10:52 UTC (permalink / raw) To: Brian Norris; +Cc: ath10k, linux-wireless, linux-kernel, stable, Wen Gong [-- Attachment #1: Type: text/plain, Size: 5013 bytes --] On Wed, May 27, 2020 at 09:57:18AM -0700, Brian Norris wrote: > 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 > 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? To the best of my knowledge I'm using the latest that's currently available, which seems to contradict this. I've added the relevant dmesg snippets though in case I'm mistaken: ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002) ath10k_pci 0000:03:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci 0000:04:00.0: enabling device (0000 -> 0002) ath10k_pci 0000:04:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci 0000:03:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0000:03:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0 ath10k_pci 0000:03:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43 ath10k_pci 0000:04:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0000:04:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0 ath10k_pci 0000:04:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43 ath10k_pci 0000:03:00.0: board_file api 2 bmi_id 0:1 crc32 85498734 ath10k_pci 0000:04:00.0: board_file api 2 bmi_id 0:2 crc32 85498734 ath10k_pci 0000:03:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath: EEPROM regdomain sanitized ath: EEPROM regdomain: 0x64 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x64 ath10k_pci 0000:04:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath: EEPROM regdomain sanitized ath: EEPROM regdomain: 0x64 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x64 Patrick [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-04-23 10:52 ` Patrick Steinhardt 0 siblings, 0 replies; 40+ messages in thread From: Patrick Steinhardt @ 2022-04-23 10:52 UTC (permalink / raw) To: Brian Norris; +Cc: ath10k, linux-wireless, linux-kernel, stable, Wen Gong [-- Attachment #1.1: Type: text/plain, Size: 5013 bytes --] On Wed, May 27, 2020 at 09:57:18AM -0700, Brian Norris wrote: > 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 > 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? To the best of my knowledge I'm using the latest that's currently available, which seems to contradict this. I've added the relevant dmesg snippets though in case I'm mistaken: ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002) ath10k_pci 0000:03:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci 0000:04:00.0: enabling device (0000 -> 0002) ath10k_pci 0000:04:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci 0000:03:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0000:03:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0 ath10k_pci 0000:03:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43 ath10k_pci 0000:04:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0000:04:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0 ath10k_pci 0000:04:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43 ath10k_pci 0000:03:00.0: board_file api 2 bmi_id 0:1 crc32 85498734 ath10k_pci 0000:04:00.0: board_file api 2 bmi_id 0:2 crc32 85498734 ath10k_pci 0000:03:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath: EEPROM regdomain sanitized ath: EEPROM regdomain: 0x64 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x64 ath10k_pci 0000:04:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath: EEPROM regdomain sanitized ath: EEPROM regdomain: 0x64 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x64 Patrick [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 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" 2022-04-23 10:52 ` Patrick Steinhardt @ 2022-04-25 18:54 ` Brian Norris -1 siblings, 0 replies; 40+ messages in thread From: Brian Norris @ 2022-04-25 18:54 UTC (permalink / raw) To: Patrick Steinhardt; +Cc: ath10k, linux-wireless, Linux Kernel, stable Hi Patrick, On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <ps@pks.im> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-04-25 18:54 ` Brian Norris 0 siblings, 0 replies; 40+ messages in thread From: Brian Norris @ 2022-04-25 18:54 UTC (permalink / raw) To: Patrick Steinhardt; +Cc: ath10k, linux-wireless, Linux Kernel, stable Hi Patrick, On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <ps@pks.im> 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 _______________________________________________ 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" 2022-04-25 18:54 ` Brian Norris @ 2022-05-09 18:16 ` Cale Collins -1 siblings, 0 replies; 40+ messages in thread From: Cale Collins @ 2022-05-09 18:16 UTC (permalink / raw) To: Brian Norris, Kalle Valo Cc: Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Tim Harvey, Stephen McCarthy 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 www.gateworks.com On Mon, Apr 25, 2022 at 11:55 AM Brian Norris <briannorris@chromium.org> wrote: > > Hi Patrick, > > On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <ps@pks.im> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-05-09 18:16 ` Cale Collins 0 siblings, 0 replies; 40+ messages in thread From: Cale Collins @ 2022-05-09 18:16 UTC (permalink / raw) To: Brian Norris, Kalle Valo Cc: Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Tim Harvey, Stephen McCarthy 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 www.gateworks.com On Mon, Apr 25, 2022 at 11:55 AM Brian Norris <briannorris@chromium.org> wrote: > > Hi Patrick, > > On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <ps@pks.im> 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 _______________________________________________ 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" 2022-05-09 18:16 ` Cale Collins @ 2022-05-11 22:52 ` Cale Collins -1 siblings, 0 replies; 40+ messages in thread From: Cale Collins @ 2022-05-11 22:52 UTC (permalink / raw) To: kvalo, Brian Norris Cc: Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Tim Harvey, Stephen McCarthy Adding Kalle, I got his address wrong the first time. On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@gateworks.com> 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 > www.gateworks.com > > > > On Mon, Apr 25, 2022 at 11:55 AM Brian Norris <briannorris@chromium.org> wrote: > > > > Hi Patrick, > > > > On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <ps@pks.im> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-05-11 22:52 ` Cale Collins 0 siblings, 0 replies; 40+ messages in thread From: Cale Collins @ 2022-05-11 22:52 UTC (permalink / raw) To: kvalo, Brian Norris Cc: Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Tim Harvey, Stephen McCarthy Adding Kalle, I got his address wrong the first time. On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@gateworks.com> 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 > www.gateworks.com > > > > On Mon, Apr 25, 2022 at 11:55 AM Brian Norris <briannorris@chromium.org> wrote: > > > > Hi Patrick, > > > > On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt <ps@pks.im> 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 _______________________________________________ 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" 2022-05-11 22:52 ` Cale Collins @ 2022-08-30 21:56 ` Brian Norris -1 siblings, 0 replies; 40+ messages in thread From: Brian Norris @ 2022-08-30 21:56 UTC (permalink / raw) To: Cale Collins Cc: kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Tim Harvey, Stephen McCarthy 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 <ccollins@gateworks.com> wrote: > On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@gateworks.com> 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 _______________________________________________ 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" @ 2022-08-30 21:56 ` Brian Norris 0 siblings, 0 replies; 40+ messages in thread From: Brian Norris @ 2022-08-30 21:56 UTC (permalink / raw) To: Cale Collins Cc: kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Tim Harvey, Stephen McCarthy 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 <ccollins@gateworks.com> wrote: > On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@gateworks.com> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" 2022-08-30 21:56 ` Brian Norris @ 2022-09-19 17:24 ` Tim Harvey -1 siblings, 0 replies; 40+ messages in thread From: Tim Harvey @ 2022-09-19 17:24 UTC (permalink / raw) To: Brian Norris Cc: Cale Collins, kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Stephen McCarthy On Tue, Aug 30, 2022 at 2:57 PM Brian Norris <briannorris@chromium.org> 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 <ccollins@gateworks.com> wrote: > > On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@gateworks.com> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-09-19 17:24 ` Tim Harvey 0 siblings, 0 replies; 40+ messages in thread From: Tim Harvey @ 2022-09-19 17:24 UTC (permalink / raw) To: Brian Norris Cc: Cale Collins, kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Stephen McCarthy On Tue, Aug 30, 2022 at 2:57 PM Brian Norris <briannorris@chromium.org> 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 <ccollins@gateworks.com> wrote: > > On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@gateworks.com> 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 _______________________________________________ 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" 2022-09-19 17:24 ` Tim Harvey @ 2022-09-19 23:42 ` Sergey Ryazanov -1 siblings, 0 replies; 40+ messages in thread From: Sergey Ryazanov @ 2022-09-19 23:42 UTC (permalink / raw) To: Tim Harvey Cc: Brian Norris, Cale Collins, kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Stephen McCarthy Hello, I would like to add my 2c. On Mon, Sep 19, 2022 at 8:25 PM Tim Harvey <tharvey@gateworks.com> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2022-09-19 23:42 ` Sergey Ryazanov 0 siblings, 0 replies; 40+ messages in thread From: Sergey Ryazanov @ 2022-09-19 23:42 UTC (permalink / raw) To: Tim Harvey Cc: Brian Norris, Cale Collins, kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Stephen McCarthy Hello, I would like to add my 2c. On Mon, Sep 19, 2022 at 8:25 PM Tim Harvey <tharvey@gateworks.com> 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 _______________________________________________ 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" 2022-09-19 23:42 ` Sergey Ryazanov @ 2022-09-20 5:42 ` Sebastian Gottschall -1 siblings, 0 replies; 40+ messages in thread From: Sebastian Gottschall @ 2022-09-20 5:42 UTC (permalink / raw) To: Sergey Ryazanov, Tim Harvey Cc: Brian Norris, Cale Collins, kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Stephen McCarthy 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 <tharvey@gateworks.com> 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 > _______________________________________________ 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" @ 2022-09-20 5:42 ` Sebastian Gottschall 0 siblings, 0 replies; 40+ messages in thread From: Sebastian Gottschall @ 2022-09-20 5:42 UTC (permalink / raw) To: Sergey Ryazanov, Tim Harvey Cc: Brian Norris, Cale Collins, kvalo, Patrick Steinhardt, ath10k, linux-wireless, Linux Kernel, stable, Stephen McCarthy 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 <tharvey@gateworks.com> 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 > ^ 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 related [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: Luis R . Rodriguez, Wen Gong, linux-wireless, Alvin Šipraga 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" 2020-07-30 12:49 ` Alvin Šipraga @ 2020-08-27 7:59 ` Alvin Šipraga -1 siblings, 0 replies; 40+ messages in thread From: Alvin Šipraga @ 2020-08-27 7:59 UTC (permalink / raw) To: Wen Gong, kvalo; +Cc: ath10k, Luis R . Rodriguez, linux-wireless 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 <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(-) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2020-08-27 7:59 ` Alvin Šipraga 0 siblings, 0 replies; 40+ messages in thread From: Alvin Šipraga @ 2020-08-27 7:59 UTC (permalink / raw) To: Wen Gong, kvalo; +Cc: Luis R . Rodriguez, linux-wireless, ath10k 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 <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(-) 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 _______________________________________________ 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-08-27 7:59 ` Alvin Šipraga @ 2020-08-27 10:12 ` Kalle Valo -1 siblings, 0 replies; 40+ messages in thread From: Kalle Valo @ 2020-08-27 10:12 UTC (permalink / raw) To: Alvin Šipraga; +Cc: Wen Gong, Luis R . Rodriguez, linux-wireless, ath10k Alvin Šipraga <alsi@bang-olufsen.dk> 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 <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(-) > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2020-08-27 10:12 ` Kalle Valo 0 siblings, 0 replies; 40+ messages in thread From: Kalle Valo @ 2020-08-27 10:12 UTC (permalink / raw) To: Alvin Šipraga; +Cc: Luis R . Rodriguez, linux-wireless, ath10k, Wen Gong Alvin Šipraga <alsi@bang-olufsen.dk> 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 <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(-) > > 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 _______________________________________________ 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-08-27 10:12 ` Kalle Valo @ 2020-08-27 10:25 ` Alvin Šipraga -1 siblings, 0 replies; 40+ messages in thread From: Alvin Šipraga @ 2020-08-27 10:25 UTC (permalink / raw) To: Kalle Valo; +Cc: Wen Gong, Luis R . Rodriguez, linux-wireless, ath10k On 8/27/20 12:12 PM, Kalle Valo wrote: > Alvin Šipraga <alsi@bang-olufsen.dk> 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 <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(-) >> >> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" @ 2020-08-27 10:25 ` Alvin Šipraga 0 siblings, 0 replies; 40+ messages in thread From: Alvin Šipraga @ 2020-08-27 10:25 UTC (permalink / raw) To: Kalle Valo; +Cc: Luis R . Rodriguez, linux-wireless, ath10k, Wen Gong On 8/27/20 12:12 PM, Kalle Valo wrote: > Alvin Šipraga <alsi@bang-olufsen.dk> 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 <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(-) >> >> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ 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
[parent not found: <CANe27jKpYm29QOjYOZ_jwHiRxuWx66J+th8-zgbXK4geiCU0_Q@mail.gmail.com>]
* Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" [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 0 siblings, 1 reply; 40+ messages in thread From: Félix Sipma @ 2020-10-29 14:06 UTC (permalink / raw) To: Jouni Malinen; +Cc: ath10k [-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --] Hi, Thanks for your detailed answer. I made a detailed report, with dmesg outputs of different kernel/firmware-atheros and wireless-regdb combinations at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970679 Massimo Maggi pointed me to this ath10k issue on the last message. Regards, On 2020-10-22 23:28+0300, Jouni Malinen wrote: >What is the exact issue you are seeing? > >> Is there something preventing >> >> https://patchwork.kernel.org/project/ath10k/patch/20200527165718.129307-1-briannorris@chromium.org/ >> from being merged? > >That seems to have a risk of mapping the default country code (CTRY_DEFAULT >is defined to be 0 in regd.h) being mapped to something else than a safe >world roaming case and this could have an impact throughout all drivers >using the generic ath/regd.c implementation. It looks like the correct >thing to do is to map an unexpected value to the safest option instead of >allowing this to be mapped to something that could end up enabling >incorrect regulatory rules. > >- Jouni -- 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-10-29 14:06 ` Félix Sipma @ 2020-10-30 7:20 ` Jouni Malinen 2020-10-30 8:51 ` Félix Sipma 2020-10-30 13:23 ` Alvin Sipraga 0 siblings, 2 replies; 40+ messages in thread From: Jouni Malinen @ 2020-10-30 7:20 UTC (permalink / raw) To: Félix Sipma; +Cc: ath10k On Thu, Oct 29, 2020 at 4:06 PM Félix Sipma <felix+kernel@gueux.org> wrote: > I made a detailed report, with dmesg outputs of different > kernel/firmware-atheros and wireless-regdb combinations at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970679 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. - Jouni _______________________________________________ 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-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 1 sibling, 1 reply; 40+ messages in thread From: Félix Sipma @ 2020-10-30 8:51 UTC (permalink / raw) To: Jouni Malinen; +Cc: ath10k [-- Attachment #1.1: Type: text/plain, Size: 2860 bytes --] On 2020-10-30 09:20+0200, Jouni Malinen wrote: >On Thu, Oct 29, 2020 at 4:06 PM Félix Sipma <felix+kernel@gueux.org> wrote: >> I made a detailed report, with dmesg outputs of different >> kernel/firmware-atheros and wireless-regdb combinations at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970679 > >So the issue is in not being able to operate an AP on the 5 GHz band? Yes, sorry for not being clear about this. >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. So, if I understand well, the new behaviour (non working AP with ac) is expected, given that the device was not provisioned with the settings specifics to my zone? And to prevent people from operating an AP with the wrong settings, we force them to use hardware that is specific to their zone? If that's the intention, I'm not sure it is very effective: I can still buy a German wifi card and use it in France. It will probably suits most of the hardware vendors, though: people moving to another country are forced to buy new stuff and they can't buy cheaper stuff abroad, but, seen from another angle, it sounds like planned obsolescence. The vendor of my (new) hardware is from Switzerland, and is selling to (at least) everywhere in Europe, and they sell the same hardware (that used to work) for everybody. So, now, they are supposed to sell specific hardware for each country? I think the card was not provisioned with a specific country (I'm in France, and I tried FR, CH, US, ...), so I guess I have to throw it to the bin anyway (and they should do the same with all their stocks). I hope I have misunderstood your message, else I have to admit I'm a little disappointed... Thanks for your explanation, though! If that's really the intention, is there a workaround for irresponsible people like me, who just wan't to avoid buying new stuff? 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-10-30 8:51 ` Félix Sipma @ 2020-12-20 1:32 ` Julian Phillips 0 siblings, 0 replies; 40+ messages in thread From: Julian Phillips @ 2020-12-20 1:32 UTC (permalink / raw) To: ath10k Hello, Has a decision been reached as to whether or not this commit will be reverted? It appears to still exist in kernel 5.10. I too have a Compex WLE900VX QCA986x/988x 802.11ac card and am affected. I purchased the card from Switzerland and am running it in Canada. I've been using the v5.4 LTS kernel as a temporary workaround, but given 5.10 will be the next LTS it would be helpful to have a definitive answer one way or another on this issue so those of us who are affected can plan accordingly. The last update I'm aware of is Alvin's argument to revert the patch: https://lists.infradead.org/pipermail/ath10k/2020-October/012049.html . Kind regards, Julian From: ath10k <ath10k-bounces@lists.infradead.org> on behalf of Félix Sipma <felix+kernel@gueux.org> Sent: October 30, 2020 8:51 AM To: Jouni Malinen <jkmalinen@gmail.com> Cc: ath10k@lists.infradead.org <ath10k@lists.infradead.org> Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" On 2020-10-30 09:20+0200, Jouni Malinen wrote: >On Thu, Oct 29, 2020 at 4:06 PM Félix Sipma <felix+kernel@gueux.org> wrote: >> I made a detailed report, with dmesg outputs of different >> kernel/firmware-atheros and wireless-regdb combinations at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970679 > >So the issue is in not being able to operate an AP on the 5 GHz band? Yes, sorry for not being clear about this. >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. So, if I understand well, the new behaviour (non working AP with ac) is expected, given that the device was not provisioned with the settings specifics to my zone? And to prevent people from operating an AP with the wrong settings, we force them to use hardware that is specific to their zone? If that's the intention, I'm not sure it is very effective: I can still buy a German wifi card and use it in France. It will probably suits most of the hardware vendors, though: people moving to another country are forced to buy new stuff and they can't buy cheaper stuff abroad, but, seen from another angle, it sounds like planned obsolescence. The vendor of my (new) hardware is from Switzerland, and is selling to (at least) everywhere in Europe, and they sell the same hardware (that used to work) for everybody. So, now, they are supposed to sell specific hardware for each country? I think the card was not provisioned with a specific country (I'm in France, and I tried FR, CH, US, ...), so I guess I have to throw it to the bin anyway (and they should do the same with all their stocks). I hope I have misunderstood your message, else I have to admit I'm a little disappointed... Thanks for your explanation, though! If that's really the intention, is there a workaround for irresponsible people like me, who just wan't to avoid buying new stuff? Regards, -- Félix _______________________________________________ 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-10-30 7:20 ` Jouni Malinen 2020-10-30 8:51 ` Félix Sipma @ 2020-10-30 13:23 ` Alvin Sipraga 2020-12-21 13:43 ` sparks71 1 sibling, 1 reply; 40+ messages in thread From: Alvin Sipraga @ 2020-10-30 13:23 UTC (permalink / raw) To: Jouni Malinen; +Cc: ath10k, Félix Sipma Hi, 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 [1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain [2] https://web.archive.org/web/20150117040022/http://article.gmane.org/gmane.linux.kernel.wireless.general/38410 [3] https://patchwork.kernel.org/project/ath10k/patch/20200730124923.271429-1-alsi@bang-olufsen.dk/ [4] https://fccid.io/TK4WLE900VX _______________________________________________ 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-10-30 13:23 ` Alvin Sipraga @ 2020-12-21 13:43 ` sparks71 0 siblings, 0 replies; 40+ messages in thread From: sparks71 @ 2020-12-21 13:43 UTC (permalink / raw) To: Alvin Sipraga, Jouni Malinen; +Cc: Félix Sipma, ath10k Am 30.10.20 um 14:23 schrieb Alvin Sipraga: > Hi, > > 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 > > [1] > https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain > [2] > https://web.archive.org/web/20150117040022/http://article.gmane.org/gmane.linux.kernel.wireless.general/38410 > [3] > https://patchwork.kernel.org/project/ath10k/patch/20200730124923.271429-1-alsi@bang-olufsen.dk/ > [4] https://fccid.io/TK4WLE900VX > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k 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 (sorry for breaking the list) _______________________________________________ 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.