| Message ID | 20200527165718.129307-1-briannorris@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Revert "ath: add support for special 0x0 regulatory domain" | expand |
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,
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
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;
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(-)