diff mbox series

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

Message ID 20200527165718.129307-1-briannorris@chromium.org (mailing list archive)
State Accepted
Commit 1ec7ed5163c70a0d040150d2279f932c7e7c143f
Delegated to: Kalle Valo
Headers show
Series Revert "ath: add support for special 0x0 regulatory domain" | expand

Commit Message

Brian Norris May 27, 2020, 4:57 p.m. UTC
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(-)

Comments

Julian Calaby May 28, 2020, 12:02 p.m. UTC | #1
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,
Brian Norris June 2, 2020, 6:35 p.m. UTC | #2
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
Kalle Valo March 7, 2022, 5:45 p.m. UTC | #3
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"
Patrick Steinhardt April 23, 2022, 10:52 a.m. UTC | #4
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
Brian Norris April 25, 2022, 6:54 p.m. UTC | #5
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
Cale Collins May 9, 2022, 6:16 p.m. UTC | #6
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
Cale Collins May 11, 2022, 10:52 p.m. UTC | #7
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
diff mbox series

Patch

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;