Message-ID: <CAJ+vNU38WyC=FFZVgqyKunEnjXid6vXqkorv8a8+ywjJBk_0NA@mail.gmail.com>
Date:   Mon, 19 Sep 2022 10:24:51 -0700
From:   Tim Harvey <tharvey@...eworks.com>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Cale Collins <ccollins@...eworks.com>, kvalo@...nel.org,
        Patrick Steinhardt <ps@....im>,
        ath10k <ath10k@...ts.infradead.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Stephen McCarthy <stephen.mccarthy@...el.com>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

On Tue, Aug 30, 2022 at 2:57 PM Brian Norris <briannorris@...omium.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@...eworks.com> wrote:
> > On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@...eworks.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@...al-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

Powered by blists - more mailing lists