Bug#927710: ath10k locks to regulatory domain US on ACPI platforms
- To: "Rene 'Renne' Bartsch, B.Sc. Informatics" <rene@bartschnet.de>, 927710@bugs.debian.org
- Subject: Bug#927710: ath10k locks to regulatory domain US on ACPI platforms
- From: Salvatore Bonaccorso <carnil@debian.org>
- Date: Sat, 29 May 2021 14:23:22 +0200
- Message-id: <YLIyOhmr2SP/v4mR@eldamar.lan>
- Reply-to: Salvatore Bonaccorso <carnil@debian.org>, 927710@bugs.debian.org
- In-reply-to: <26bce3e4-5e25-29d0-630c-092ed44ad00f@bartschnet.de>
- References: <26bce3e4-5e25-29d0-630c-092ed44ad00f@bartschnet.de> <26bce3e4-5e25-29d0-630c-092ed44ad00f@bartschnet.de>
Control: tags -1 + moreinfo
Hi,
On Sun, Apr 21, 2019 at 09:48:17PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> Package: linux-image
> Version: 4.19.28-2
>
> The ath10k 802.11 driver reads the country code for the radio regulatory domain from the ACPI table.
> If it can't get a valid value it locks to US regulatory domain which is wrong for most countries.
> This makes Atheros devices in master mode unusable on ACPI devices in most countries.
>
> Sven Gottschall suggested on ath10k mailing-list to return -EOPNOTSUPP in function
> ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd) in file drivers/net/wireless/ath/ath10k/mac.c to solve this.
>
>
> static int ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd)
> {
> return -EOPNOTSUPP;
> }
Was there a conclusion upstream?
Regards,
Salvatore
Reply to: