From: Brian Norris <briannorris@chromium.org> To: Patrick Steinhardt <ps@pks.im> Cc: ath10k <ath10k@lists.infradead.org>, linux-wireless <linux-wireless@vger.kernel.org>, Linux Kernel <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org> Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" Date: Mon, 25 Apr 2022 11:54:00 -0700 [thread overview] Message-ID: <CA+ASDXPeJ6fD9hvc0Nq_RY05YRdSP77U_96vUZcTYgkQKY9Bvg@mail.gmail.com> (raw) In-Reply-To: <YmPadTu8CfEARfWs@xps> 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 (diff)
From: Brian Norris <briannorris@chromium.org> To: Patrick Steinhardt <ps@pks.im> Cc: ath10k <ath10k@lists.infradead.org>, linux-wireless <linux-wireless@vger.kernel.org>, Linux Kernel <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org> Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" Date: Mon, 25 Apr 2022 11:54:00 -0700 [thread overview] Message-ID: <CA+ASDXPeJ6fD9hvc0Nq_RY05YRdSP77U_96vUZcTYgkQKY9Bvg@mail.gmail.com> (raw) In-Reply-To: <YmPadTu8CfEARfWs@xps> 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
next prev parent reply other threads:[~2022-04-25 18:54 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 [this message] 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
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+ASDXPeJ6fD9hvc0Nq_RY05YRdSP77U_96vUZcTYgkQKY9Bvg@mail.gmail.com \ --to=briannorris@chromium.org \ --cc=ath10k@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=ps@pks.im \ --cc=stable@vger.kernel.org \ /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.