linux-kernel - Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YmPadTu8CfEARfWs@xps>
Date:   Sat, 23 Apr 2022 12:52:37 +0200
From:   Patrick Steinhardt <ps@....im>
To:     Brian Norris <briannorris@...omium.org>
Cc:     ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Wen Gong <wgong@...eaurora.org>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory
 domain"

On Wed, May 27, 2020 at 09:57:18AM -0700, Brian Norris 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:
> 
>     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@...r.kernel.org>
> Cc: Wen Gong <wgong@...eaurora.org>
> Signed-off-by: Brian Norris <briannorris@...omium.org>
> ---
>  drivers/net/wireless/ath/regd.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> 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;
> -- 
> 2.27.0.rc0.183.gde8f92d652-goog
> 

This revert is in fact causing problems on my machine. I have a QCA9984,
which exports two network interfaces. While I was able to still use one
of both NICs for 2.4GHz, I couldn't really use the other card to set up
a 5GHz AP anymore because all frequencies were restricted. This has
started with v5.17.1, to which this revert was backported.

Reverting this patch again fixes the issue on my system. So it seems
like there still are cards out there in the wild which have a value of
0x0 as their regulatory domain.

Quoting from your other mail:

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

This sounds like the issue should've already been fixed in firmware,
right? To the best of my knowledge I'm using the latest that's currently
available, which seems to contradict this. I've added the relevant dmesg
snippets though in case I'm mistaken:

    ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002)
    ath10k_pci 0000:03:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
    ath10k_pci 0000:04:00.0: enabling device (0000 -> 0002)
    ath10k_pci 0000:04:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
    ath10k_pci 0000:03:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
    ath10k_pci 0000:03:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0
    ath10k_pci 0000:03:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43
    ath10k_pci 0000:04:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
    ath10k_pci 0000:04:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0
    ath10k_pci 0000:04:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43
    ath10k_pci 0000:03:00.0: board_file api 2 bmi_id 0:1 crc32 85498734
    ath10k_pci 0000:04:00.0: board_file api 2 bmi_id 0:2 crc32 85498734
    ath10k_pci 0000:03:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
    ath: EEPROM regdomain sanitized
    ath: EEPROM regdomain: 0x64
    ath: EEPROM indicates we should expect a direct regpair map
    ath: Country alpha2 being used: 00
    ath: Regpair used: 0x64
    ath10k_pci 0000:04:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
    ath: EEPROM regdomain sanitized
    ath: EEPROM regdomain: 0x64
    ath: EEPROM indicates we should expect a direct regpair map
    ath: Country alpha2 being used: 00
    ath: Regpair used: 0x64

Patrick

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)