From: Brian Norris <briannorris@chromium.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Julian Calaby <julian.calaby@gmail.com>, ath10k <ath10k@lists.infradead.org>, linux-wireless <linux-wireless@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>, Wen Gong <wgong@codeaurora.org> Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" Date: Tue, 2 Jun 2020 11:35:43 -0700 [thread overview] Message-ID: <CA+ASDXNicJmAKvkjD5mGFVQ+bmz8nHT_A1oqtjoS=spRSFP70A@mail.gmail.com> (raw) In-Reply-To: <CAJ-Vmomx0UFEa1w2HsGMQsZb+K8hyK=Zz9cKSo7tHv5GiMc1yw@mail.gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Julian Calaby <julian.calaby@gmail.com>, linux-wireless <linux-wireless@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>, ath10k <ath10k@lists.infradead.org>, Wen Gong <wgong@codeaurora.org> Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" Date: Tue, 2 Jun 2020 11:35:43 -0700 [thread overview] Message-ID: <CA+ASDXNicJmAKvkjD5mGFVQ+bmz8nHT_A1oqtjoS=spRSFP70A@mail.gmail.com> (raw) In-Reply-To: <CAJ-Vmomx0UFEa1w2HsGMQsZb+K8hyK=Zz9cKSo7tHv5GiMc1yw@mail.gmail.com> 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
next prev parent reply other threads:[~2020-06-02 18:36 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 [this message] 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
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+ASDXNicJmAKvkjD5mGFVQ+bmz8nHT_A1oqtjoS=spRSFP70A@mail.gmail.com' \ --to=briannorris@chromium.org \ --cc=adrian@freebsd.org \ --cc=ath10k@lists.infradead.org \ --cc=julian.calaby@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=stable@vger.kernel.org \ --cc=wgong@codeaurora.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.