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/39ef369cbca269fa32e8f85d31a...
Best Regards,
Tim