2019-11-23 09:58:40 +02:00
|
|
|
// SPDX-License-Identifier: BSD-3-Clause-Clear
|
|
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
|
|
|
|
|
*/
|
2021-12-21 11:39:41 -08:00
|
|
|
#include <linux/rtnetlink.h>
|
|
|
|
|
|
2019-11-23 09:58:40 +02:00
|
|
|
#include "core.h"
|
|
|
|
|
#include "debug.h"
|
|
|
|
|
|
|
|
|
|
/* World regdom to be used in case default regd from fw is unavailable */
|
|
|
|
|
#define ATH11K_2GHZ_CH01_11 REG_RULE(2412 - 10, 2462 + 10, 40, 0, 20, 0)
|
|
|
|
|
#define ATH11K_5GHZ_5150_5350 REG_RULE(5150 - 10, 5350 + 10, 80, 0, 30,\
|
|
|
|
|
NL80211_RRF_NO_IR)
|
|
|
|
|
#define ATH11K_5GHZ_5725_5850 REG_RULE(5725 - 10, 5850 + 10, 80, 0, 30,\
|
|
|
|
|
NL80211_RRF_NO_IR)
|
|
|
|
|
|
|
|
|
|
#define ETSI_WEATHER_RADAR_BAND_LOW 5590
|
|
|
|
|
#define ETSI_WEATHER_RADAR_BAND_HIGH 5650
|
|
|
|
|
#define ETSI_WEATHER_RADAR_BAND_CAC_TIMEOUT 600000
|
|
|
|
|
|
|
|
|
|
static const struct ieee80211_regdomain ath11k_world_regd = {
|
|
|
|
|
.n_reg_rules = 3,
|
|
|
|
|
.alpha2 = "00",
|
|
|
|
|
.reg_rules = {
|
|
|
|
|
ATH11K_2GHZ_CH01_11,
|
|
|
|
|
ATH11K_5GHZ_5150_5350,
|
|
|
|
|
ATH11K_5GHZ_5725_5850,
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static bool ath11k_regdom_changes(struct ath11k *ar, char *alpha2)
|
|
|
|
|
{
|
|
|
|
|
const struct ieee80211_regdomain *regd;
|
|
|
|
|
|
|
|
|
|
regd = rcu_dereference_rtnl(ar->hw->wiphy->regd);
|
|
|
|
|
/* This can happen during wiphy registration where the previous
|
|
|
|
|
* user request is received before we update the regd received
|
|
|
|
|
* from firmware.
|
|
|
|
|
*/
|
|
|
|
|
if (!regd)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
return memcmp(regd->alpha2, alpha2, 2) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ath11k_reg_notifier(struct wiphy *wiphy, struct regulatory_request *request)
|
|
|
|
|
{
|
|
|
|
|
struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
|
|
|
|
|
struct wmi_init_country_params init_country_param;
|
2022-01-18 23:13:55 -05:00
|
|
|
struct wmi_set_current_country_params set_current_param = {};
|
2019-11-23 09:58:40 +02:00
|
|
|
struct ath11k *ar = hw->priv;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG,
|
|
|
|
|
"Regulatory Notification received for %s\n", wiphy_name(wiphy));
|
|
|
|
|
|
|
|
|
|
/* Currently supporting only General User Hints. Cell base user
|
|
|
|
|
* hints to be handled later.
|
|
|
|
|
* Hints from other sources like Core, Beacons are not expected for
|
|
|
|
|
* self managed wiphy's
|
|
|
|
|
*/
|
|
|
|
|
if (!(request->initiator == NL80211_REGDOM_SET_BY_USER &&
|
|
|
|
|
request->user_reg_hint_type == NL80211_USER_REG_HINT_USER)) {
|
|
|
|
|
ath11k_warn(ar->ab, "Unexpected Regulatory event for this wiphy\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS)) {
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG,
|
|
|
|
|
"Country Setting is not allowed\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!ath11k_regdom_changes(ar, request->alpha2)) {
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG, "Country is already set\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-18 23:13:55 -05:00
|
|
|
/* Set the country code to the firmware and will receive
|
2019-11-23 09:58:40 +02:00
|
|
|
* the WMI_REG_CHAN_LIST_CC EVENT for updating the
|
|
|
|
|
* reg info
|
|
|
|
|
*/
|
2022-01-18 23:13:55 -05:00
|
|
|
if (ar->ab->hw_params.current_cc_support) {
|
|
|
|
|
memcpy(&set_current_param.alpha2, request->alpha2, 2);
|
2022-03-23 21:18:56 -04:00
|
|
|
memcpy(&ar->alpha2, &set_current_param.alpha2, 2);
|
2022-01-18 23:13:55 -05:00
|
|
|
ret = ath11k_wmi_send_set_current_country_cmd(ar, &set_current_param);
|
|
|
|
|
if (ret)
|
|
|
|
|
ath11k_warn(ar->ab,
|
|
|
|
|
"failed set current country code: %d\n", ret);
|
|
|
|
|
} else {
|
|
|
|
|
init_country_param.flags = ALPHA_IS_SET;
|
|
|
|
|
memcpy(&init_country_param.cc_info.alpha2, request->alpha2, 2);
|
|
|
|
|
init_country_param.cc_info.alpha2[2] = 0;
|
|
|
|
|
|
|
|
|
|
ret = ath11k_wmi_send_init_country_cmd(ar, init_country_param);
|
|
|
|
|
if (ret)
|
|
|
|
|
ath11k_warn(ar->ab,
|
|
|
|
|
"INIT Country code set to fw failed : %d\n", ret);
|
|
|
|
|
}
|
2021-12-07 17:23:36 +02:00
|
|
|
|
|
|
|
|
ath11k_mac_11d_scan_stop(ar);
|
|
|
|
|
ar->regdom_set_by_user = true;
|
2019-11-23 09:58:40 +02:00
|
|
|
}
|
|
|
|
|
|
ath11k: reduce the wait time of 11d scan and hw scan while add interface
Currently ath11k will wait 11d scan complete while add interface in
ath11k_mac_op_add_interface(), when system resume without enable
wowlan, ath11k_mac_op_add_interface() is called for each resume, thus
it increase the resume time of system. And ath11k_mac_op_hw_scan()
after ath11k_mac_op_add_interface() also needs some time cost because
the previous 11d scan need more than 5 seconds when 6 GHz is enabled,
then the scan started event will indicated to ath11k after the 11d
scan completed.
While 11d scan/hw scan is running in firmware, if ath11k update channel
list to firmware by WMI_SCAN_CHAN_LIST_CMDID, then firmware will cancel
the current scan which is running, it lead the scan failed. The patch
commit 9dcf6808b253 ("ath11k: add 11d scan offload support") used
finish_11d_scan/finish_11d_ch_list/pending_11d to synchronize the 11d
scan/hw scan/channel list between ath11k/firmware/mac80211 and to avoid
the scan fail.
Add wait operation before ath11k update channel list, function
ath11k_reg_update_chan_list() will wait until the current 11d scan/hw
scan completed. And remove the wait operation of start 11d scan and
waiting channel list complete in hw scan. After these changes, resume
time cost reduce about 5 seconds and also hw scan time cost reduced
obviously, and scan failed not seen.
The 11d scan is sent to firmware only one time for each interface added
in mac.c, and it is moved after the 1st hw scan because 11d scan will
cost some time and thus leads the AP scan result update to UI delay.
Currently priority of ath11k's hw scan is WMI_SCAN_PRIORITY_LOW, and
priority of 11d scan in firmware is WMI_SCAN_PRIORITY_MEDIUM, then the
11d scan which sent after hw scan will cancel the hw scan in firmware,
so change the priority to WMI_SCAN_PRIORITY_MEDIUM for the hw scan which
is in front of the 11d scan, thus it will not happen scan cancel in
firmware.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: 9dcf6808b253 ("ath11k: add 11d scan offload support")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220328035832.14122-1-quic_wgong@quicinc.com
2022-03-27 23:58:32 -04:00
|
|
|
int ath11k_reg_update_chan_list(struct ath11k *ar, bool wait)
|
2019-11-23 09:58:40 +02:00
|
|
|
{
|
|
|
|
|
struct ieee80211_supported_band **bands;
|
|
|
|
|
struct scan_chan_list_params *params;
|
|
|
|
|
struct ieee80211_channel *channel;
|
|
|
|
|
struct ieee80211_hw *hw = ar->hw;
|
|
|
|
|
struct channel_param *ch;
|
|
|
|
|
enum nl80211_band band;
|
|
|
|
|
int num_channels = 0;
|
ath11k: reduce the wait time of 11d scan and hw scan while add interface
Currently ath11k will wait 11d scan complete while add interface in
ath11k_mac_op_add_interface(), when system resume without enable
wowlan, ath11k_mac_op_add_interface() is called for each resume, thus
it increase the resume time of system. And ath11k_mac_op_hw_scan()
after ath11k_mac_op_add_interface() also needs some time cost because
the previous 11d scan need more than 5 seconds when 6 GHz is enabled,
then the scan started event will indicated to ath11k after the 11d
scan completed.
While 11d scan/hw scan is running in firmware, if ath11k update channel
list to firmware by WMI_SCAN_CHAN_LIST_CMDID, then firmware will cancel
the current scan which is running, it lead the scan failed. The patch
commit 9dcf6808b253 ("ath11k: add 11d scan offload support") used
finish_11d_scan/finish_11d_ch_list/pending_11d to synchronize the 11d
scan/hw scan/channel list between ath11k/firmware/mac80211 and to avoid
the scan fail.
Add wait operation before ath11k update channel list, function
ath11k_reg_update_chan_list() will wait until the current 11d scan/hw
scan completed. And remove the wait operation of start 11d scan and
waiting channel list complete in hw scan. After these changes, resume
time cost reduce about 5 seconds and also hw scan time cost reduced
obviously, and scan failed not seen.
The 11d scan is sent to firmware only one time for each interface added
in mac.c, and it is moved after the 1st hw scan because 11d scan will
cost some time and thus leads the AP scan result update to UI delay.
Currently priority of ath11k's hw scan is WMI_SCAN_PRIORITY_LOW, and
priority of 11d scan in firmware is WMI_SCAN_PRIORITY_MEDIUM, then the
11d scan which sent after hw scan will cancel the hw scan in firmware,
so change the priority to WMI_SCAN_PRIORITY_MEDIUM for the hw scan which
is in front of the 11d scan, thus it will not happen scan cancel in
firmware.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: 9dcf6808b253 ("ath11k: add 11d scan offload support")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220328035832.14122-1-quic_wgong@quicinc.com
2022-03-27 23:58:32 -04:00
|
|
|
int i, ret, left;
|
|
|
|
|
|
|
|
|
|
if (wait && ar->state_11d != ATH11K_11D_IDLE) {
|
|
|
|
|
left = wait_for_completion_timeout(&ar->completed_11d_scan,
|
|
|
|
|
ATH11K_SCAN_TIMEOUT_HZ);
|
|
|
|
|
if (!left) {
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG,
|
|
|
|
|
"failed to receive 11d scan complete: timed out\n");
|
|
|
|
|
ar->state_11d = ATH11K_11D_IDLE;
|
|
|
|
|
}
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG,
|
|
|
|
|
"reg 11d scan wait left time %d\n", left);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (wait &&
|
|
|
|
|
(ar->scan.state == ATH11K_SCAN_STARTING ||
|
|
|
|
|
ar->scan.state == ATH11K_SCAN_RUNNING)) {
|
|
|
|
|
left = wait_for_completion_timeout(&ar->scan.completed,
|
|
|
|
|
ATH11K_SCAN_TIMEOUT_HZ);
|
|
|
|
|
if (!left)
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG,
|
|
|
|
|
"failed to receive hw scan complete: timed out\n");
|
|
|
|
|
|
|
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_REG,
|
|
|
|
|
"reg hw scan wait left time %d\n", left);
|
|
|
|
|
}
|
2019-11-23 09:58:40 +02:00
|
|
|
|
ath11k: reset 11d state in process of recovery
When doing simulate_fw_crash operation periodically with a short interval
time such as 10 seconds, it is easy happened WMI command timed out for
WMI_SCAN_CHAN_LIST_CMDID in ath11k_reg_update_chan_list().
log:
[42287.610053] ath11k_pci 0000:01:00.0: wmi command 12291 timeout
[42287.610064] ath11k_pci 0000:01:00.0: failed to send WMI_SCAN_CHAN_LIST cmd
[42287.610073] ath11k_pci 0000:01:00.0: failed to perform regd update : -11
Note that this issue does not occur with a longer interval such as 20 seconds.
The reason the issue occurs with a shorter interval is the following steps:
1) Upon initial boot, or after device recovery, the initial hw scan plus
the 11d scan will run, and when 6 GHz support is present, these scans
can take up to 12 seconds to complete, so ath11k_reg_update_chan_list()
is still waiting the completion of ar->completed_11d_scan.
2) If a simulate_fw_crash operation is received during this time, those
scans do not complete, and ath11k_core_pre_reconfigure_recovery()
complete the ar->completed_11d_scan, then ath11k_reg_update_chan_list()
wakeup and start to send WMI_SCAN_CHAN_LIST_CMDID, but firmware is crashed
at this moment, so wmi timed out occur.
To address this issue, reset the 11d state during device recovery so that
WMI_SCAN_CHAN_LIST_CMDID does not timed out for short interval time such
as 10 seconds.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: 1f682dc9fb37 ("ath11k: reduce the wait time of 11d scan and hw scan while add interface")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220505034636.29582-1-quic_wgong@quicinc.com
2022-05-04 23:46:36 -04:00
|
|
|
if (ar->state == ATH11K_STATE_RESTARTING)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-11-23 09:58:40 +02:00
|
|
|
bands = hw->wiphy->bands;
|
|
|
|
|
for (band = 0; band < NUM_NL80211_BANDS; band++) {
|
|
|
|
|
if (!bands[band])
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < bands[band]->n_channels; i++) {
|
|
|
|
|
if (bands[band]->channels[i].flags &
|
|
|
|
|
IEEE80211_CHAN_DISABLED)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
num_channels++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (WARN_ON(!num_channels))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
ath11k: Replace one-element array with flexible-array member
There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code
should always use "flexible array members"[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refactor the code a bit according to the use of a flexible-array member in
struct scan_chan_list_params instead of a one-element array, and use the
struct_size() helper.
Also, save 25 (too many) bytes that were being allocated:
$ pahole -C channel_param drivers/net/wireless/ath/ath11k/reg.o
struct channel_param {
u8 chan_id; /* 0 1 */
u8 pwr; /* 1 1 */
u32 mhz; /* 2 4 */
/* Bitfield combined with next fields */
u32 half_rate:1; /* 4:16 4 */
u32 quarter_rate:1; /* 4:17 4 */
u32 dfs_set:1; /* 4:18 4 */
u32 dfs_set_cfreq2:1; /* 4:19 4 */
u32 is_chan_passive:1; /* 4:20 4 */
u32 allow_ht:1; /* 4:21 4 */
u32 allow_vht:1; /* 4:22 4 */
u32 allow_he:1; /* 4:23 4 */
u32 set_agile:1; /* 4:24 4 */
u32 psc_channel:1; /* 4:25 4 */
/* XXX 6 bits hole, try to pack */
u32 phy_mode; /* 8 4 */
u32 cfreq1; /* 12 4 */
u32 cfreq2; /* 16 4 */
char maxpower; /* 20 1 */
char minpower; /* 21 1 */
char maxregpower; /* 22 1 */
u8 antennamax; /* 23 1 */
u8 reg_class_id; /* 24 1 */
/* size: 25, cachelines: 1, members: 21 */
/* sum members: 23 */
/* sum bitfield members: 10 bits, bit holes: 1, sum bit holes: 6 bits */
/* last cacheline: 25 bytes */
} __attribute__((__packed__));
as previously, sizeof(struct scan_chan_list_params) was 32 bytes:
$ pahole -C scan_chan_list_params drivers/net/wireless/ath/ath11k/reg.o
struct scan_chan_list_params {
u32 pdev_id; /* 0 4 */
u16 nallchans; /* 4 2 */
struct channel_param ch_param[1]; /* 6 25 */
/* size: 32, cachelines: 1, members: 3 */
/* padding: 1 */
/* last cacheline: 32 bytes */
};
and now with the flexible array transformation it is just 8 bytes:
$ pahole -C scan_chan_list_params drivers/net/wireless/ath/ath11k/reg.o
struct scan_chan_list_params {
u32 pdev_id; /* 0 4 */
u16 nallchans; /* 4 2 */
struct channel_param ch_param[]; /* 6 0 */
/* size: 8, cachelines: 1, members: 3 */
/* padding: 2 */
/* last cacheline: 8 bytes */
};
This helps with the ongoing efforts to globally enable -Warray-bounds and
get us closer to being able to tighten the FORTIFY_SOURCE routines on
memcpy().
This issue was found with the help of Coccinelle and audited and fixed,
manually.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/109
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210823172159.GA25800@embeddedor
2021-09-28 12:05:44 +03:00
|
|
|
params = kzalloc(struct_size(params, ch_param, num_channels),
|
|
|
|
|
GFP_KERNEL);
|
2019-11-23 09:58:40 +02:00
|
|
|
if (!params)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
params->pdev_id = ar->pdev->pdev_id;
|
|
|
|
|
params->nallchans = num_channels;
|
|
|
|
|
|
|
|
|
|
ch = params->ch_param;
|
|
|
|
|
|
|
|
|
|
for (band = 0; band < NUM_NL80211_BANDS; band++) {
|
|
|
|
|
if (!bands[band])
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < bands[band]->n_channels; i++) {
|
|
|
|
|
channel = &bands[band]->channels[i];
|
|
|
|
|
|
|
|
|
|
if (channel->flags & IEEE80211_CHAN_DISABLED)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* TODO: Set to true/false based on some condition? */
|
|
|
|
|
ch->allow_ht = true;
|
|
|
|
|
ch->allow_vht = true;
|
2019-11-25 16:36:27 +00:00
|
|
|
ch->allow_he = true;
|
2019-11-23 09:58:40 +02:00
|
|
|
|
|
|
|
|
ch->dfs_set =
|
|
|
|
|
!!(channel->flags & IEEE80211_CHAN_RADAR);
|
|
|
|
|
ch->is_chan_passive = !!(channel->flags &
|
|
|
|
|
IEEE80211_CHAN_NO_IR);
|
|
|
|
|
ch->is_chan_passive |= ch->dfs_set;
|
|
|
|
|
ch->mhz = channel->center_freq;
|
|
|
|
|
ch->cfreq1 = channel->center_freq;
|
|
|
|
|
ch->minpower = 0;
|
|
|
|
|
ch->maxpower = channel->max_power * 2;
|
|
|
|
|
ch->maxregpower = channel->max_reg_power * 2;
|
|
|
|
|
ch->antennamax = channel->max_antenna_gain * 2;
|
|
|
|
|
|
|
|
|
|
/* TODO: Use appropriate phymodes */
|
|
|
|
|
if (channel->band == NL80211_BAND_2GHZ)
|
|
|
|
|
ch->phy_mode = MODE_11G;
|
|
|
|
|
else
|
|
|
|
|
ch->phy_mode = MODE_11A;
|
|
|
|
|
|
2020-06-09 09:31:03 +03:00
|
|
|
if (channel->band == NL80211_BAND_6GHZ &&
|
|
|
|
|
cfg80211_channel_is_psc(channel))
|
|
|
|
|
ch->psc_channel = true;
|
|
|
|
|
|
2019-11-23 09:58:40 +02:00
|
|
|
ath11k_dbg(ar->ab, ATH11K_DBG_WMI,
|
|
|
|
|
"mac channel [%d/%d] freq %d maxpower %d regpower %d antenna %d mode %d\n",
|
|
|
|
|
i, params->nallchans,
|
|
|
|
|
ch->mhz, ch->maxpower, ch->maxregpower,
|
|
|
|
|
ch->antennamax, ch->phy_mode);
|
|
|
|
|
|
|
|
|
|
ch++;
|
|
|
|
|
/* TODO: use quarrter/half rate, cfreq12, dfs_cfreq2
|
|
|
|
|
* set_agile, reg_class_idx
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = ath11k_wmi_send_scan_chan_list_cmd(ar, params);
|
|
|
|
|
kfree(params);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ath11k_copy_regd(struct ieee80211_regdomain *regd_orig,
|
|
|
|
|
struct ieee80211_regdomain *regd_copy)
|
|
|
|
|
{
|
|
|
|
|
u8 i;
|
|
|
|
|
|
|
|
|
|
/* The caller should have checked error conditions */
|
|
|
|
|
memcpy(regd_copy, regd_orig, sizeof(*regd_orig));
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < regd_orig->n_reg_rules; i++)
|
|
|
|
|
memcpy(®d_copy->reg_rules[i], ®d_orig->reg_rules[i],
|
|
|
|
|
sizeof(struct ieee80211_reg_rule));
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-28 12:05:40 +03:00
|
|
|
int ath11k_regd_update(struct ath11k *ar)
|
2019-11-23 09:58:40 +02:00
|
|
|
{
|
|
|
|
|
struct ieee80211_regdomain *regd, *regd_copy = NULL;
|
|
|
|
|
int ret, regd_len, pdev_id;
|
|
|
|
|
struct ath11k_base *ab;
|
|
|
|
|
|
|
|
|
|
ab = ar->ab;
|
|
|
|
|
pdev_id = ar->pdev_idx;
|
|
|
|
|
|
2020-09-29 20:15:34 +03:00
|
|
|
spin_lock_bh(&ab->base_lock);
|
2019-11-23 09:58:40 +02:00
|
|
|
|
2021-09-28 12:05:40 +03:00
|
|
|
/* Prefer the latest regd update over default if it's available */
|
|
|
|
|
if (ab->new_regd[pdev_id]) {
|
|
|
|
|
regd = ab->new_regd[pdev_id];
|
|
|
|
|
} else {
|
2019-11-23 09:58:40 +02:00
|
|
|
/* Apply the regd received during init through
|
|
|
|
|
* WMI_REG_CHAN_LIST_CC event. In case of failure to
|
|
|
|
|
* receive the regd, initialize with a default world
|
|
|
|
|
* regulatory.
|
|
|
|
|
*/
|
|
|
|
|
if (ab->default_regd[pdev_id]) {
|
|
|
|
|
regd = ab->default_regd[pdev_id];
|
|
|
|
|
} else {
|
|
|
|
|
ath11k_warn(ab,
|
|
|
|
|
"failed to receive default regd during init\n");
|
|
|
|
|
regd = (struct ieee80211_regdomain *)&ath11k_world_regd;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!regd) {
|
|
|
|
|
ret = -EINVAL;
|
2020-09-29 20:15:34 +03:00
|
|
|
spin_unlock_bh(&ab->base_lock);
|
2019-11-23 09:58:40 +02:00
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
regd_len = sizeof(*regd) + (regd->n_reg_rules *
|
|
|
|
|
sizeof(struct ieee80211_reg_rule));
|
|
|
|
|
|
|
|
|
|
regd_copy = kzalloc(regd_len, GFP_ATOMIC);
|
|
|
|
|
if (regd_copy)
|
|
|
|
|
ath11k_copy_regd(regd, regd_copy);
|
|
|
|
|
|
2020-09-29 20:15:34 +03:00
|
|
|
spin_unlock_bh(&ab->base_lock);
|
2019-11-23 09:58:40 +02:00
|
|
|
|
|
|
|
|
if (!regd_copy) {
|
|
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rtnl_lock();
|
2021-01-22 16:19:43 +01:00
|
|
|
wiphy_lock(ar->hw->wiphy);
|
|
|
|
|
ret = regulatory_set_wiphy_regd_sync(ar->hw->wiphy, regd_copy);
|
|
|
|
|
wiphy_unlock(ar->hw->wiphy);
|
2019-11-23 09:58:40 +02:00
|
|
|
rtnl_unlock();
|
|
|
|
|
|
|
|
|
|
kfree(regd_copy);
|
|
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
|
|
if (ar->state == ATH11K_STATE_ON) {
|
ath11k: reduce the wait time of 11d scan and hw scan while add interface
Currently ath11k will wait 11d scan complete while add interface in
ath11k_mac_op_add_interface(), when system resume without enable
wowlan, ath11k_mac_op_add_interface() is called for each resume, thus
it increase the resume time of system. And ath11k_mac_op_hw_scan()
after ath11k_mac_op_add_interface() also needs some time cost because
the previous 11d scan need more than 5 seconds when 6 GHz is enabled,
then the scan started event will indicated to ath11k after the 11d
scan completed.
While 11d scan/hw scan is running in firmware, if ath11k update channel
list to firmware by WMI_SCAN_CHAN_LIST_CMDID, then firmware will cancel
the current scan which is running, it lead the scan failed. The patch
commit 9dcf6808b253 ("ath11k: add 11d scan offload support") used
finish_11d_scan/finish_11d_ch_list/pending_11d to synchronize the 11d
scan/hw scan/channel list between ath11k/firmware/mac80211 and to avoid
the scan fail.
Add wait operation before ath11k update channel list, function
ath11k_reg_update_chan_list() will wait until the current 11d scan/hw
scan completed. And remove the wait operation of start 11d scan and
waiting channel list complete in hw scan. After these changes, resume
time cost reduce about 5 seconds and also hw scan time cost reduced
obviously, and scan failed not seen.
The 11d scan is sent to firmware only one time for each interface added
in mac.c, and it is moved after the 1st hw scan because 11d scan will
cost some time and thus leads the AP scan result update to UI delay.
Currently priority of ath11k's hw scan is WMI_SCAN_PRIORITY_LOW, and
priority of 11d scan in firmware is WMI_SCAN_PRIORITY_MEDIUM, then the
11d scan which sent after hw scan will cancel the hw scan in firmware,
so change the priority to WMI_SCAN_PRIORITY_MEDIUM for the hw scan which
is in front of the 11d scan, thus it will not happen scan cancel in
firmware.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: 9dcf6808b253 ("ath11k: add 11d scan offload support")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220328035832.14122-1-quic_wgong@quicinc.com
2022-03-27 23:58:32 -04:00
|
|
|
ret = ath11k_reg_update_chan_list(ar, true);
|
2019-11-23 09:58:40 +02:00
|
|
|
if (ret)
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
err:
|
|
|
|
|
ath11k_warn(ab, "failed to perform regd update : %d\n", ret);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static enum nl80211_dfs_regions
|
|
|
|
|
ath11k_map_fw_dfs_region(enum ath11k_dfs_region dfs_region)
|
|
|
|
|
{
|
|
|
|
|
switch (dfs_region) {
|
|
|
|
|
case ATH11K_DFS_REG_FCC:
|
|
|
|
|
case ATH11K_DFS_REG_CN:
|
|
|
|
|
return NL80211_DFS_FCC;
|
|
|
|
|
case ATH11K_DFS_REG_ETSI:
|
|
|
|
|
case ATH11K_DFS_REG_KR:
|
|
|
|
|
return NL80211_DFS_ETSI;
|
|
|
|
|
case ATH11K_DFS_REG_MKK:
|
2020-11-05 13:34:35 +05:30
|
|
|
case ATH11K_DFS_REG_MKK_N:
|
2019-11-23 09:58:40 +02:00
|
|
|
return NL80211_DFS_JP;
|
|
|
|
|
default:
|
|
|
|
|
return NL80211_DFS_UNSET;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static u32 ath11k_map_fw_reg_flags(u16 reg_flags)
|
|
|
|
|
{
|
|
|
|
|
u32 flags = 0;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_NO_IR)
|
|
|
|
|
flags = NL80211_RRF_NO_IR;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_RADAR)
|
|
|
|
|
flags |= NL80211_RRF_DFS;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_NO_OFDM)
|
|
|
|
|
flags |= NL80211_RRF_NO_OFDM;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_INDOOR_ONLY)
|
|
|
|
|
flags |= NL80211_RRF_NO_OUTDOOR;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_NO_HT40)
|
|
|
|
|
flags |= NL80211_RRF_NO_HT40;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_NO_80MHZ)
|
|
|
|
|
flags |= NL80211_RRF_NO_80MHZ;
|
|
|
|
|
|
|
|
|
|
if (reg_flags & REGULATORY_CHAN_NO_160MHZ)
|
|
|
|
|
flags |= NL80211_RRF_NO_160MHZ;
|
|
|
|
|
|
|
|
|
|
return flags;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
ath11k_reg_can_intersect(struct ieee80211_reg_rule *rule1,
|
|
|
|
|
struct ieee80211_reg_rule *rule2)
|
|
|
|
|
{
|
|
|
|
|
u32 start_freq1, end_freq1;
|
|
|
|
|
u32 start_freq2, end_freq2;
|
|
|
|
|
|
|
|
|
|
start_freq1 = rule1->freq_range.start_freq_khz;
|
|
|
|
|
start_freq2 = rule2->freq_range.start_freq_khz;
|
|
|
|
|
|
|
|
|
|
end_freq1 = rule1->freq_range.end_freq_khz;
|
|
|
|
|
end_freq2 = rule2->freq_range.end_freq_khz;
|
|
|
|
|
|
|
|
|
|
if ((start_freq1 >= start_freq2 &&
|
|
|
|
|
start_freq1 < end_freq2) ||
|
|
|
|
|
(start_freq2 > start_freq1 &&
|
|
|
|
|
start_freq2 < end_freq1))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/* TODO: Should we restrict intersection feasibility
|
|
|
|
|
* based on min bandwidth of the intersected region also,
|
|
|
|
|
* say the intersected rule should have a min bandwidth
|
|
|
|
|
* of 20MHz?
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ath11k_reg_intersect_rules(struct ieee80211_reg_rule *rule1,
|
|
|
|
|
struct ieee80211_reg_rule *rule2,
|
|
|
|
|
struct ieee80211_reg_rule *new_rule)
|
|
|
|
|
{
|
|
|
|
|
u32 start_freq1, end_freq1;
|
|
|
|
|
u32 start_freq2, end_freq2;
|
|
|
|
|
u32 freq_diff, max_bw;
|
|
|
|
|
|
|
|
|
|
start_freq1 = rule1->freq_range.start_freq_khz;
|
|
|
|
|
start_freq2 = rule2->freq_range.start_freq_khz;
|
|
|
|
|
|
|
|
|
|
end_freq1 = rule1->freq_range.end_freq_khz;
|
|
|
|
|
end_freq2 = rule2->freq_range.end_freq_khz;
|
|
|
|
|
|
|
|
|
|
new_rule->freq_range.start_freq_khz = max_t(u32, start_freq1,
|
|
|
|
|
start_freq2);
|
|
|
|
|
new_rule->freq_range.end_freq_khz = min_t(u32, end_freq1, end_freq2);
|
|
|
|
|
|
|
|
|
|
freq_diff = new_rule->freq_range.end_freq_khz -
|
|
|
|
|
new_rule->freq_range.start_freq_khz;
|
|
|
|
|
max_bw = min_t(u32, rule1->freq_range.max_bandwidth_khz,
|
|
|
|
|
rule2->freq_range.max_bandwidth_khz);
|
|
|
|
|
new_rule->freq_range.max_bandwidth_khz = min_t(u32, max_bw, freq_diff);
|
|
|
|
|
|
|
|
|
|
new_rule->power_rule.max_antenna_gain =
|
|
|
|
|
min_t(u32, rule1->power_rule.max_antenna_gain,
|
|
|
|
|
rule2->power_rule.max_antenna_gain);
|
|
|
|
|
|
|
|
|
|
new_rule->power_rule.max_eirp = min_t(u32, rule1->power_rule.max_eirp,
|
|
|
|
|
rule2->power_rule.max_eirp);
|
|
|
|
|
|
|
|
|
|
/* Use the flags of both the rules */
|
|
|
|
|
new_rule->flags = rule1->flags | rule2->flags;
|
|
|
|
|
|
|
|
|
|
/* To be safe, lts use the max cac timeout of both rules */
|
|
|
|
|
new_rule->dfs_cac_ms = max_t(u32, rule1->dfs_cac_ms,
|
|
|
|
|
rule2->dfs_cac_ms);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct ieee80211_regdomain *
|
|
|
|
|
ath11k_regd_intersect(struct ieee80211_regdomain *default_regd,
|
|
|
|
|
struct ieee80211_regdomain *curr_regd)
|
|
|
|
|
{
|
|
|
|
|
u8 num_old_regd_rules, num_curr_regd_rules, num_new_regd_rules;
|
|
|
|
|
struct ieee80211_reg_rule *old_rule, *curr_rule, *new_rule;
|
|
|
|
|
struct ieee80211_regdomain *new_regd = NULL;
|
|
|
|
|
u8 i, j, k;
|
|
|
|
|
|
|
|
|
|
num_old_regd_rules = default_regd->n_reg_rules;
|
|
|
|
|
num_curr_regd_rules = curr_regd->n_reg_rules;
|
|
|
|
|
num_new_regd_rules = 0;
|
|
|
|
|
|
|
|
|
|
/* Find the number of intersecting rules to allocate new regd memory */
|
|
|
|
|
for (i = 0; i < num_old_regd_rules; i++) {
|
|
|
|
|
old_rule = default_regd->reg_rules + i;
|
|
|
|
|
for (j = 0; j < num_curr_regd_rules; j++) {
|
|
|
|
|
curr_rule = curr_regd->reg_rules + j;
|
|
|
|
|
|
|
|
|
|
if (ath11k_reg_can_intersect(old_rule, curr_rule))
|
|
|
|
|
num_new_regd_rules++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!num_new_regd_rules)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
new_regd = kzalloc(sizeof(*new_regd) + (num_new_regd_rules *
|
|
|
|
|
sizeof(struct ieee80211_reg_rule)),
|
|
|
|
|
GFP_ATOMIC);
|
|
|
|
|
|
|
|
|
|
if (!new_regd)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
/* We set the new country and dfs region directly and only trim
|
|
|
|
|
* the freq, power, antenna gain by intersecting with the
|
|
|
|
|
* default regdomain. Also MAX of the dfs cac timeout is selected.
|
|
|
|
|
*/
|
|
|
|
|
new_regd->n_reg_rules = num_new_regd_rules;
|
|
|
|
|
memcpy(new_regd->alpha2, curr_regd->alpha2, sizeof(new_regd->alpha2));
|
|
|
|
|
new_regd->dfs_region = curr_regd->dfs_region;
|
|
|
|
|
new_rule = new_regd->reg_rules;
|
|
|
|
|
|
|
|
|
|
for (i = 0, k = 0; i < num_old_regd_rules; i++) {
|
|
|
|
|
old_rule = default_regd->reg_rules + i;
|
|
|
|
|
for (j = 0; j < num_curr_regd_rules; j++) {
|
|
|
|
|
curr_rule = curr_regd->reg_rules + j;
|
|
|
|
|
|
|
|
|
|
if (ath11k_reg_can_intersect(old_rule, curr_rule))
|
|
|
|
|
ath11k_reg_intersect_rules(old_rule, curr_rule,
|
|
|
|
|
(new_rule + k++));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return new_regd;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
|
ath11k_reg_get_regdom_str(enum nl80211_dfs_regions dfs_region)
|
|
|
|
|
{
|
|
|
|
|
switch (dfs_region) {
|
|
|
|
|
case NL80211_DFS_FCC:
|
|
|
|
|
return "FCC";
|
|
|
|
|
case NL80211_DFS_ETSI:
|
|
|
|
|
return "ETSI";
|
|
|
|
|
case NL80211_DFS_JP:
|
|
|
|
|
return "JP";
|
|
|
|
|
default:
|
|
|
|
|
return "UNSET";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static u16
|
|
|
|
|
ath11k_reg_adjust_bw(u16 start_freq, u16 end_freq, u16 max_bw)
|
|
|
|
|
{
|
|
|
|
|
u16 bw;
|
|
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
if (end_freq <= start_freq)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-11-23 09:58:40 +02:00
|
|
|
bw = end_freq - start_freq;
|
|
|
|
|
bw = min_t(u16, bw, max_bw);
|
|
|
|
|
|
|
|
|
|
if (bw >= 80 && bw < 160)
|
|
|
|
|
bw = 80;
|
|
|
|
|
else if (bw >= 40 && bw < 80)
|
|
|
|
|
bw = 40;
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
else if (bw >= 20 && bw < 40)
|
2019-11-23 09:58:40 +02:00
|
|
|
bw = 20;
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
else
|
|
|
|
|
bw = 0;
|
2019-11-23 09:58:40 +02:00
|
|
|
|
|
|
|
|
return bw;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ath11k_reg_update_rule(struct ieee80211_reg_rule *reg_rule, u32 start_freq,
|
|
|
|
|
u32 end_freq, u32 bw, u32 ant_gain, u32 reg_pwr,
|
|
|
|
|
u32 reg_flags)
|
|
|
|
|
{
|
|
|
|
|
reg_rule->freq_range.start_freq_khz = MHZ_TO_KHZ(start_freq);
|
|
|
|
|
reg_rule->freq_range.end_freq_khz = MHZ_TO_KHZ(end_freq);
|
|
|
|
|
reg_rule->freq_range.max_bandwidth_khz = MHZ_TO_KHZ(bw);
|
|
|
|
|
reg_rule->power_rule.max_antenna_gain = DBI_TO_MBI(ant_gain);
|
|
|
|
|
reg_rule->power_rule.max_eirp = DBM_TO_MBM(reg_pwr);
|
|
|
|
|
reg_rule->flags = reg_flags;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ath11k_reg_update_weather_radar_band(struct ath11k_base *ab,
|
|
|
|
|
struct ieee80211_regdomain *regd,
|
|
|
|
|
struct cur_reg_rule *reg_rule,
|
|
|
|
|
u8 *rule_idx, u32 flags, u16 max_bw)
|
|
|
|
|
{
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
u32 start_freq;
|
2019-11-23 09:58:40 +02:00
|
|
|
u32 end_freq;
|
|
|
|
|
u16 bw;
|
|
|
|
|
u8 i;
|
|
|
|
|
|
|
|
|
|
i = *rule_idx;
|
|
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
/* there might be situations when even the input rule must be dropped */
|
|
|
|
|
i--;
|
|
|
|
|
|
|
|
|
|
/* frequencies below weather radar */
|
2019-11-23 09:58:40 +02:00
|
|
|
bw = ath11k_reg_adjust_bw(reg_rule->start_freq,
|
|
|
|
|
ETSI_WEATHER_RADAR_BAND_LOW, max_bw);
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
if (bw > 0) {
|
|
|
|
|
i++;
|
|
|
|
|
|
|
|
|
|
ath11k_reg_update_rule(regd->reg_rules + i,
|
|
|
|
|
reg_rule->start_freq,
|
|
|
|
|
ETSI_WEATHER_RADAR_BAND_LOW, bw,
|
|
|
|
|
reg_rule->ant_gain, reg_rule->reg_power,
|
|
|
|
|
flags);
|
|
|
|
|
|
|
|
|
|
ath11k_dbg(ab, ATH11K_DBG_REG,
|
|
|
|
|
"\t%d. (%d - %d @ %d) (%d, %d) (%d ms) (FLAGS %d)\n",
|
|
|
|
|
i + 1, reg_rule->start_freq,
|
|
|
|
|
ETSI_WEATHER_RADAR_BAND_LOW, bw, reg_rule->ant_gain,
|
|
|
|
|
reg_rule->reg_power, regd->reg_rules[i].dfs_cac_ms,
|
|
|
|
|
flags);
|
|
|
|
|
}
|
2019-11-23 09:58:40 +02:00
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
/* weather radar frequencies */
|
|
|
|
|
start_freq = max_t(u32, reg_rule->start_freq,
|
|
|
|
|
ETSI_WEATHER_RADAR_BAND_LOW);
|
|
|
|
|
end_freq = min_t(u32, reg_rule->end_freq, ETSI_WEATHER_RADAR_BAND_HIGH);
|
2019-11-23 09:58:40 +02:00
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
bw = ath11k_reg_adjust_bw(start_freq, end_freq, max_bw);
|
|
|
|
|
if (bw > 0) {
|
|
|
|
|
i++;
|
2019-11-23 09:58:40 +02:00
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
ath11k_reg_update_rule(regd->reg_rules + i, start_freq,
|
|
|
|
|
end_freq, bw, reg_rule->ant_gain,
|
|
|
|
|
reg_rule->reg_power, flags);
|
2019-11-23 09:58:40 +02:00
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
regd->reg_rules[i].dfs_cac_ms = ETSI_WEATHER_RADAR_BAND_CAC_TIMEOUT;
|
2019-11-23 09:58:40 +02:00
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
ath11k_dbg(ab, ATH11K_DBG_REG,
|
|
|
|
|
"\t%d. (%d - %d @ %d) (%d, %d) (%d ms) (FLAGS %d)\n",
|
|
|
|
|
i + 1, start_freq, end_freq, bw,
|
|
|
|
|
reg_rule->ant_gain, reg_rule->reg_power,
|
|
|
|
|
regd->reg_rules[i].dfs_cac_ms, flags);
|
2019-11-23 09:58:40 +02:00
|
|
|
}
|
|
|
|
|
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
/* frequencies above weather radar */
|
2019-11-23 09:58:40 +02:00
|
|
|
bw = ath11k_reg_adjust_bw(ETSI_WEATHER_RADAR_BAND_HIGH,
|
|
|
|
|
reg_rule->end_freq, max_bw);
|
ath11k: Fix ETSI regd with weather radar overlap
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
2021-11-15 11:29:55 +02:00
|
|
|
if (bw > 0) {
|
|
|
|
|
i++;
|
|
|
|
|
|
|
|
|
|
ath11k_reg_update_rule(regd->reg_rules + i,
|
|
|
|
|
ETSI_WEATHER_RADAR_BAND_HIGH,
|
|
|
|
|
reg_rule->end_freq, bw,
|
|
|
|
|
reg_rule->ant_gain, reg_rule->reg_power,
|
|
|
|
|
flags);
|
|
|
|
|
|
|
|
|
|
ath11k_dbg(ab, ATH11K_DBG_REG,
|
|
|
|
|
"\t%d. (%d - %d @ %d) (%d, %d) (%d ms) (FLAGS %d)\n",
|
|
|
|
|
i + 1, ETSI_WEATHER_RADAR_BAND_HIGH,
|
|
|
|
|
reg_rule->end_freq, bw, reg_rule->ant_gain,
|
|
|
|
|
reg_rule->reg_power, regd->reg_rules[i].dfs_cac_ms,
|
|
|
|
|
flags);
|
|
|
|
|
}
|
2019-11-23 09:58:40 +02:00
|
|
|
|
|
|
|
|
*rule_idx = i;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ieee80211_regdomain *
|
|
|
|
|
ath11k_reg_build_regd(struct ath11k_base *ab,
|
|
|
|
|
struct cur_regulatory_info *reg_info, bool intersect)
|
|
|
|
|
{
|
|
|
|
|
struct ieee80211_regdomain *tmp_regd, *default_regd, *new_regd = NULL;
|
|
|
|
|
struct cur_reg_rule *reg_rule;
|
|
|
|
|
u8 i = 0, j = 0;
|
|
|
|
|
u8 num_rules;
|
|
|
|
|
u16 max_bw;
|
|
|
|
|
u32 flags;
|
|
|
|
|
char alpha2[3];
|
|
|
|
|
|
|
|
|
|
num_rules = reg_info->num_5g_reg_rules + reg_info->num_2g_reg_rules;
|
|
|
|
|
|
|
|
|
|
if (!num_rules)
|
|
|
|
|
goto ret;
|
|
|
|
|
|
|
|
|
|
/* Add max additional rules to accommodate weather radar band */
|
|
|
|
|
if (reg_info->dfs_region == ATH11K_DFS_REG_ETSI)
|
|
|
|
|
num_rules += 2;
|
|
|
|
|
|
|
|
|
|
tmp_regd = kzalloc(sizeof(*tmp_regd) +
|
|
|
|
|
(num_rules * sizeof(struct ieee80211_reg_rule)),
|
|
|
|
|
GFP_ATOMIC);
|
|
|
|
|
if (!tmp_regd)
|
|
|
|
|
goto ret;
|
|
|
|
|
|
|
|
|
|
memcpy(tmp_regd->alpha2, reg_info->alpha2, REG_ALPHA2_LEN + 1);
|
|
|
|
|
memcpy(alpha2, reg_info->alpha2, REG_ALPHA2_LEN + 1);
|
|
|
|
|
alpha2[2] = '\0';
|
|
|
|
|
tmp_regd->dfs_region = ath11k_map_fw_dfs_region(reg_info->dfs_region);
|
|
|
|
|
|
|
|
|
|
ath11k_dbg(ab, ATH11K_DBG_REG,
|
|
|
|
|
"\r\nCountry %s, CFG Regdomain %s FW Regdomain %d, num_reg_rules %d\n",
|
|
|
|
|
alpha2, ath11k_reg_get_regdom_str(tmp_regd->dfs_region),
|
|
|
|
|
reg_info->dfs_region, num_rules);
|
|
|
|
|
/* Update reg_rules[] below. Firmware is expected to
|
|
|
|
|
* send these rules in order(2G rules first and then 5G)
|
|
|
|
|
*/
|
2020-10-30 11:19:40 +01:00
|
|
|
for (; i < num_rules; i++) {
|
2019-11-23 09:58:40 +02:00
|
|
|
if (reg_info->num_2g_reg_rules &&
|
|
|
|
|
(i < reg_info->num_2g_reg_rules)) {
|
|
|
|
|
reg_rule = reg_info->reg_rules_2g_ptr + i;
|
|
|
|
|
max_bw = min_t(u16, reg_rule->max_bw,
|
|
|
|
|
reg_info->max_bw_2g);
|
|
|
|
|
flags = 0;
|
|
|
|
|
} else if (reg_info->num_5g_reg_rules &&
|
|
|
|
|
(j < reg_info->num_5g_reg_rules)) {
|
|
|
|
|
reg_rule = reg_info->reg_rules_5g_ptr + j++;
|
|
|
|
|
max_bw = min_t(u16, reg_rule->max_bw,
|
|
|
|
|
reg_info->max_bw_5g);
|
|
|
|
|
|
|
|
|
|
/* FW doesn't pass NL80211_RRF_AUTO_BW flag for
|
|
|
|
|
* BW Auto correction, we can enable this by default
|
|
|
|
|
* for all 5G rules here. The regulatory core performs
|
|
|
|
|
* BW correction if required and applies flags as
|
|
|
|
|
* per other BW rule flags we pass from here
|
|
|
|
|
*/
|
|
|
|
|
flags = NL80211_RRF_AUTO_BW;
|
|
|
|
|
} else {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
flags |= ath11k_map_fw_reg_flags(reg_rule->flags);
|
|
|
|
|
|
|
|
|
|
ath11k_reg_update_rule(tmp_regd->reg_rules + i,
|
|
|
|
|
reg_rule->start_freq,
|
|
|
|
|
reg_rule->end_freq, max_bw,
|
|
|
|
|
reg_rule->ant_gain, reg_rule->reg_power,
|
|
|
|
|
flags);
|
|
|
|
|
|
|
|
|
|
/* Update dfs cac timeout if the dfs domain is ETSI and the
|
|
|
|
|
* new rule covers weather radar band.
|
|
|
|
|
* Default value of '0' corresponds to 60s timeout, so no
|
|
|
|
|
* need to update that for other rules.
|
|
|
|
|
*/
|
|
|
|
|
if (flags & NL80211_RRF_DFS &&
|
|
|
|
|
reg_info->dfs_region == ATH11K_DFS_REG_ETSI &&
|
|
|
|
|
(reg_rule->end_freq > ETSI_WEATHER_RADAR_BAND_LOW &&
|
|
|
|
|
reg_rule->start_freq < ETSI_WEATHER_RADAR_BAND_HIGH)){
|
|
|
|
|
ath11k_reg_update_weather_radar_band(ab, tmp_regd,
|
|
|
|
|
reg_rule, &i,
|
|
|
|
|
flags, max_bw);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath11k_dbg(ab, ATH11K_DBG_REG,
|
|
|
|
|
"\t%d. (%d - %d @ %d) (%d, %d) (%d ms) (FLAGS %d)\n",
|
|
|
|
|
i + 1, reg_rule->start_freq, reg_rule->end_freq,
|
|
|
|
|
max_bw, reg_rule->ant_gain, reg_rule->reg_power,
|
|
|
|
|
tmp_regd->reg_rules[i].dfs_cac_ms,
|
|
|
|
|
flags);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-30 11:19:40 +01:00
|
|
|
tmp_regd->n_reg_rules = i;
|
|
|
|
|
|
2019-11-23 09:58:40 +02:00
|
|
|
if (intersect) {
|
|
|
|
|
default_regd = ab->default_regd[reg_info->phy_id];
|
|
|
|
|
|
|
|
|
|
/* Get a new regd by intersecting the received regd with
|
|
|
|
|
* our default regd.
|
|
|
|
|
*/
|
|
|
|
|
new_regd = ath11k_regd_intersect(default_regd, tmp_regd);
|
|
|
|
|
kfree(tmp_regd);
|
|
|
|
|
if (!new_regd) {
|
|
|
|
|
ath11k_warn(ab, "Unable to create intersected regdomain\n");
|
|
|
|
|
goto ret;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
new_regd = tmp_regd;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret:
|
|
|
|
|
return new_regd;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ath11k_regd_update_work(struct work_struct *work)
|
|
|
|
|
{
|
|
|
|
|
struct ath11k *ar = container_of(work, struct ath11k,
|
|
|
|
|
regd_update_work);
|
|
|
|
|
int ret;
|
|
|
|
|
|
2021-09-28 12:05:40 +03:00
|
|
|
ret = ath11k_regd_update(ar);
|
2019-11-23 09:58:40 +02:00
|
|
|
if (ret) {
|
|
|
|
|
/* Firmware has already moved to the new regd. We need
|
|
|
|
|
* to maintain channel consistency across FW, Host driver
|
|
|
|
|
* and userspace. Hence as a fallback mechanism we can set
|
|
|
|
|
* the prev or default country code to the firmware.
|
|
|
|
|
*/
|
|
|
|
|
/* TODO: Implement Fallback Mechanism */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ath11k_reg_init(struct ath11k *ar)
|
|
|
|
|
{
|
|
|
|
|
ar->hw->wiphy->regulatory_flags = REGULATORY_WIPHY_SELF_MANAGED;
|
|
|
|
|
ar->hw->wiphy->reg_notifier = ath11k_reg_notifier;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ath11k_reg_free(struct ath11k_base *ab)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
2020-06-16 17:00:46 +03:00
|
|
|
for (i = 0; i < ab->hw_params.max_radios; i++) {
|
2019-11-23 09:58:40 +02:00
|
|
|
kfree(ab->default_regd[i]);
|
|
|
|
|
kfree(ab->new_regd[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|