All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Harvey <tharvey@gateworks.com>
To: Brian Norris <briannorris@chromium.org>
Cc: Cale Collins <ccollins@gateworks.com>,
	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>,
	Stephen McCarthy <stephen.mccarthy@pctel.com>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
Date: Mon, 19 Sep 2022 10:24:51 -0700	[thread overview]
Message-ID: <CAJ+vNU38WyC=FFZVgqyKunEnjXid6vXqkorv8a8+ywjJBk_0NA@mail.gmail.com> (raw)
In-Reply-To: <CA+ASDXNx30A3=BA9b-tiAQzYHP=nV_eLw1QFpJij=F=JgWZ5sg@mail.gmail.com>

On Tue, Aug 30, 2022 at 2:57 PM Brian Norris <briannorris@chromium.org> wrote:
>
> 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,

Thanks for the follow-up. Indeed the situation Cale had here was with
Compex WLE900VX which apparently does have what we now understand to
be an unprogrammed EEPROM. I suspect this was some choice from Compex
that somehow must have benefited them at the time and I'm not clear if
there are many other cards that have this same issue. Maybe something
should be added to the ath drivers wiki pages
(https://wireless.wiki.kernel.org/en/users/drivers/ath9k)

Reverting commit 2dc016599cfa ("ath: add support for special 0x0
regulatory domain") does indeed resolve the issue on the older kernels
but somehow the issue creeps back in with later kernels (definitely
appears in 5.15) perhaps due to other changes. Perhaps you can confirm
my findings if you have a card like this.

For 5.15 and newer I've elected to add a hack from OpenWrt for the
kernel's used to support my companies boards which adds a kernel
config to not enforce EEPROM reg restrictions for the kernels that our
users use:
https://github.com/Gateworks/linux-venice/commit/39ef369cbca269fa32e8f85d31ae813b97d84aec

Best Regards,

Tim

WARNING: multiple messages have this Message-ID
From: Tim Harvey <tharvey@gateworks.com>
To: Brian Norris <briannorris@chromium.org>
Cc: Cale Collins <ccollins@gateworks.com>,
	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>,
	 Stephen McCarthy <stephen.mccarthy@pctel.com>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
Date: Mon, 19 Sep 2022 10:24:51 -0700	[thread overview]
Message-ID: <CAJ+vNU38WyC=FFZVgqyKunEnjXid6vXqkorv8a8+ywjJBk_0NA@mail.gmail.com> (raw)
In-Reply-To: <CA+ASDXNx30A3=BA9b-tiAQzYHP=nV_eLw1QFpJij=F=JgWZ5sg@mail.gmail.com>

On Tue, Aug 30, 2022 at 2:57 PM Brian Norris <briannorris@chromium.org> wrote:
>
> 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,

Thanks for the follow-up. Indeed the situation Cale had here was with
Compex WLE900VX which apparently does have what we now understand to
be an unprogrammed EEPROM. I suspect this was some choice from Compex
that somehow must have benefited them at the time and I'm not clear if
there are many other cards that have this same issue. Maybe something
should be added to the ath drivers wiki pages
(https://wireless.wiki.kernel.org/en/users/drivers/ath9k)

Reverting commit 2dc016599cfa ("ath: add support for special 0x0
regulatory domain") does indeed resolve the issue on the older kernels
but somehow the issue creeps back in with later kernels (definitely
appears in 5.15) perhaps due to other changes. Perhaps you can confirm
my findings if you have a card like this.

For 5.15 and newer I've elected to add a hack from OpenWrt for the
kernel's used to support my companies boards which adds a kernel
config to not enforce EEPROM reg restrictions for the kernels that our
users use:
https://github.com/Gateworks/linux-venice/commit/39ef369cbca269fa32e8f85d31ae813b97d84aec

Best Regards,

Tim

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2022-09-19 17:25 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
2022-08-30 21:56           ` Brian Norris
2022-09-19 17:24           ` Tim Harvey [this message]
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='CAJ+vNU38WyC=FFZVgqyKunEnjXid6vXqkorv8a8+ywjJBk_0NA@mail.gmail.com' \
    --to=tharvey@gateworks.com \
    --cc=ath10k@lists.infradead.org \
    --cc=briannorris@chromium.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 \
    /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
Be 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.