All of lore.kernel.org
 help / color / mirror / Atom feed
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
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

  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 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 \
    --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.