From: Brian Norris <briannorris@chromium.org> To: Cale Collins <ccollins@gateworks.com> Cc: kvalo@kernel.org, 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: Tue, 30 Aug 2022 14:56:51 -0700 [thread overview] Message-ID: <CA+ASDXNx30A3=BA9b-tiAQzYHP=nV_eLw1QFpJij=F=JgWZ5sg@mail.gmail.com> (raw) In-Reply-To: <CAG2Q2vXFcSVwF4CbU5o3VP1MWwrdqrZjTHgfBj_Q0t3nNipJRw@mail.gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org> To: Cale Collins <ccollins@gateworks.com> Cc: kvalo@kernel.org, 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: Tue, 30 Aug 2022 14:56:51 -0700 [thread overview] Message-ID: <CA+ASDXNx30A3=BA9b-tiAQzYHP=nV_eLw1QFpJij=F=JgWZ5sg@mail.gmail.com> (raw) In-Reply-To: <CAG2Q2vXFcSVwF4CbU5o3VP1MWwrdqrZjTHgfBj_Q0t3nNipJRw@mail.gmail.com> 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
next prev parent reply other threads:[~2022-08-30 21:57 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 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 [this message] 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='CA+ASDXNx30A3=BA9b-tiAQzYHP=nV_eLw1QFpJij=F=JgWZ5sg@mail.gmail.com' \ --to=briannorris@chromium.org \ --cc=ath10k@lists.infradead.org \ --cc=ccollins@gateworks.com \ --cc=kvalo@kernel.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 \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.