All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cale Collins <ccollins@gateworks.com>
To: Brian Norris <briannorris@chromium.org>,
	Kalle Valo <kvalo@codeaurora.org>
Cc: Patrick Steinhardt <ps@pks.im>,
	ath10k <ath10k@lists.infradead.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Tim Harvey <tharvey@gateworks.com>,
	Stephen McCarthy <stephen.mccarthy@pctel.com>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
Date: Mon, 9 May 2022 11:16:19 -0700	[thread overview]
Message-ID: <CAG2Q2vXce2V3Y6MnPhV6obcNWyQzyusMTL=5oCQLRNh2_ffNYA@mail.gmail.com> (raw)
In-Reply-To: <CA+ASDXPeJ6fD9hvc0Nq_RY05YRdSP77U_96vUZcTYgkQKY9Bvg@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID
From: Cale Collins <ccollins@gateworks.com>
To: Brian Norris <briannorris@chromium.org>,
	Kalle Valo <kvalo@codeaurora.org>
Cc: Patrick Steinhardt <ps@pks.im>,
	ath10k <ath10k@lists.infradead.org>,
	 linux-wireless <linux-wireless@vger.kernel.org>,
	 Linux Kernel <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	 Tim Harvey <tharvey@gateworks.com>,
	Stephen McCarthy <stephen.mccarthy@pctel.com>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
Date: Mon, 9 May 2022 11:16:19 -0700	[thread overview]
Message-ID: <CAG2Q2vXce2V3Y6MnPhV6obcNWyQzyusMTL=5oCQLRNh2_ffNYA@mail.gmail.com> (raw)
In-Reply-To: <CA+ASDXPeJ6fD9hvc0Nq_RY05YRdSP77U_96vUZcTYgkQKY9Bvg@mail.gmail.com>

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

  reply	other threads:[~2022-05-09 18:17 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 16:57 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAG2Q2vXce2V3Y6MnPhV6obcNWyQzyusMTL=5oCQLRNh2_ffNYA@mail.gmail.com' \
    --to=ccollins@gateworks.com \
    --cc=ath10k@lists.infradead.org \
    --cc=briannorris@chromium.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=ps@pks.im \
    --cc=stable@vger.kernel.org \
    --cc=stephen.mccarthy@pctel.com \
    --cc=tharvey@gateworks.com \
    --subject='Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.