This introduced some new concept:
power type of AP(STANDARD_POWER_AP, INDOOR_AP, VERY_LOW_POWER_AP)
power type of STATION(DEFAULT_CLIENT, SUBORDINATE_CLIENT)
power spectral density(psd)
This patchset is to implement the new rules for 6 GHz band in
ath11k.
ath11k parsed the reg rules from new WMI event
WMI_REG_CHAN_LIST_CC_EXT_EVENTID and parse the
transmit power envelope element in beacon of AP
and then set new WMI command WMI_VDEV_SET_TPC_POWER_CMDID
to firmware when connect to 6G AP, also support backward
compatibility with firmware which not support new wmi
cmd WMI_VDEV_SET_TPC_POWER_CMDID.
v6: (NOT depends to any patch now)
1. The dependent patch "wifi: cfg80211: save power spectral density(psd) of regulatory rule"
has upstream to wireless-next https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?id=ddd7f45c899f7524bdbe6a32fe4906cde8b07b9b
The prerequisite-patch is cherry-pick from wireless-next
So add back the other patches in v3 since no dependency to cfg80211 public patch above now.
[v3,08/15] wifi: ath11k: save power spectral density(psd) of regulatory rule
[v3,09/15] wifi: ath11k: add parse of transmit power envelope element
[v3,10/15] wifi: ath11k: save max tx power in vdev start response event from firmware
[v3,11/15] wifi: ath11k: fill parameters for vdev_set_tpc_power wmi command
[v3,12/15] wifi: ath11k: add WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT service bit
[v3,13/15] wifi: ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6 GHz
[v3,14/15] wifi: ath11k: add handler for WMI_VDEV_SET_TPC_POWER_CMDID
[v3,15/15] wifi: ath11k: send TPC power to firmware for 6 GHz station
2. rename some "6g" to "6ghz"
3. remove "static" for ath11k_reg_ap_pwr_convert()
4. add 20 Mhz check in ath11k_mac_get_eirp_power()
5. remove min_t() in ath11k_mac_fill_reg_tpc_info() for not is_tpe_present
6. rebased to ath-202309051328
link of v5:
[PATCH v5 0/5] fix wrong TX power and frequency in regdomain by dynamic switch 6 GHz reg rules of LPI/SP/VLP for station mode
https://lore.kernel.org/linux-wireless/[email protected]/
v5: change per Kalle and rebased to ath.git ath-202306211808
1. ath11k_ieee80211_ap_pwr_type_convert() to ath11k_reg_ap_pwr_convert()
2. used list_first_entry_or_null() and add comments
3. ath11k_dbg() to ath11k_warn()
4. ath11k_hw_supports_6g_cc_ext() to ath11k_mac_supports_6g_cc_ext()
5. add mesh in commit log
v4: (NOT depends to any patch now).
1. removed patches which depends on
wifi: cfg80211: save Power Spectral Density (PSD) of the regulatory rule
https://lore.kernel.org/linux-wireless/[email protected]/
removed:
[v3,08/15] wifi: ath11k: save power spectral density(psd) of regulatory rule
[v3,09/15] wifi: ath11k: add parse of transmit power envelope element
[v3,10/15] wifi: ath11k: save max tx power in vdev start response event from firmware
[v3,11/15] wifi: ath11k: fill parameters for vdev_set_tpc_power wmi command
[v3,12/15] wifi: ath11k: add WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT service bit
[v3,13/15] wifi: ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6 GHz
[v3,14/15] wifi: ath11k: add handler for WMI_VDEV_SET_TPC_POWER_CMDID
[v3,15/15] wifi: ath11k: send TPC power to firmware for 6 GHz station
2. rebased to ath.git ath-202304281700
3. deleted "wifi: ath11k: Add support to parse new wmi event for 6 GHz regulatory" which is alreay upstream.
link of v3:
[v3,00/15] wifi: ath11k: add support for 6 GHz station for various modes : LPI, SP and VLP
https://patchwork.kernel.org/project/linux-wireless/cover/[email protected]/
v3:
1. added "ath11k: fix a possible dead lock caused by ab->base_lock".
3. deleted "ath11k: add support for extended wmi service bit" which is alreay upstream.
v2:
1. change some minor comments by Kalle.
2. rebased to ath.git ath-202112220603
Baochen Qiang (1):
wifi: ath11k: fix a possible dead lock caused by ab->base_lock
Wen Gong (12):
wifi: ath11k: add support to select 6 GHz regulatory type
wifi: ath11k: store cur_regulatory_info for each radio
wifi: ath11k: update regulatory rules when interface added
wifi: ath11k: update regulatory rules when connect to AP on 6 GHz band
for station
wifi: ath11k: save power spectral density(psd) of regulatory rule
wifi: ath11k: add parse of transmit power envelope element
wifi: ath11k: save max tx power in vdev start response event from
firmware
wifi: ath11k: fill parameters for vdev set tpc power WMI command
wifi: ath11k: add WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT service bit
wifi: ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for
6 GHz
wifi: ath11k: add handler for WMI_VDEV_SET_TPC_POWER_CMDID
wifi: ath11k: send TPC power to firmware for 6 GHz station
drivers/net/wireless/ath/ath11k/core.h | 40 ++
drivers/net/wireless/ath/ath11k/mac.c | 518 ++++++++++++++++++++++++-
drivers/net/wireless/ath/ath11k/mac.h | 6 +-
drivers/net/wireless/ath/ath11k/reg.c | 89 ++++-
drivers/net/wireless/ath/ath11k/reg.h | 6 +-
drivers/net/wireless/ath/ath11k/wmi.c | 216 ++++++++---
drivers/net/wireless/ath/ath11k/wmi.h | 68 ++++
7 files changed, 872 insertions(+), 71 deletions(-)
base-commit: 0263687f4441d5a5eab8074d56b4693c8f0acf85
prerequisite-patch-id: f2d377ca3641f71aea67b168e3f1ec9cdf196d8f
--
2.40.1
The transmit power envelope element has some fields for power, ath11k
should parse it according to IEEE Std 802.11ax™‐2021.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/core.h | 38 +++++
drivers/net/wireless/ath/ath11k/mac.c | 185 +++++++++++++++++++++++++
2 files changed, 223 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/ath/ath11k/core.h
index 9fbe4f67218c..42e02df0526c 100644
--- a/drivers/net/wireless/ath/ath11k/core.h
+++ b/drivers/net/wireless/ath/ath11k/core.h
@@ -311,6 +311,43 @@ struct ath11k_rekey_data {
bool enable_offload;
};
+/**
+ * struct chan_power_info - TPE containing power info per channel chunk
+ * @chan_cfreq: channel center freq (MHz)
+ * e.g.
+ * channel 37/20 MHz, it is 6135
+ * channel 37/40 MHz, it is 6125
+ * channel 37/80 MHz, it is 6145
+ * channel 37/160 MHz, it is 6185
+ * @tx_power: transmit power (dBm)
+ */
+struct chan_power_info {
+ u16 chan_cfreq;
+ s8 tx_power;
+};
+
+/**
+ * struct reg_tpc_power_info - regulatory TPC power info
+ * @is_psd_power: is PSD power or not
+ * @eirp_power: Maximum EIRP power (dBm), valid only if power is PSD
+ * @ap_power_type: type of power (SP/LPI/VLP)
+ * @num_pwr_levels: number of power levels
+ * @reg_max: Array of maximum TX power (dBm) per PSD value
+ * @ap_constraint_power: AP constraint power (dBm)
+ * @tpe: TPE values processed from TPE IE
+ * @chan_power_info: power info to send to firmware
+ */
+struct ath11k_reg_tpc_power_info {
+ bool is_psd_power;
+ u8 eirp_power;
+ enum wmi_reg_6ghz_ap_type ap_power_type;
+ u8 num_pwr_levels;
+ u8 reg_max[IEEE80211_MAX_NUM_PWR_LEVEL];
+ u8 ap_constraint_power;
+ s8 tpe[IEEE80211_MAX_NUM_PWR_LEVEL];
+ struct chan_power_info chan_power_info[IEEE80211_MAX_NUM_PWR_LEVEL];
+};
+
struct ath11k_vif {
u32 vdev_id;
enum wmi_vdev_type vdev_type;
@@ -369,6 +406,7 @@ struct ath11k_vif {
#ifdef CONFIG_ATH11K_DEBUGFS
struct dentry *debugfs_twt;
#endif /* CONFIG_ATH11K_DEBUGFS */
+ struct ath11k_reg_tpc_power_info reg_tpc_info;
};
struct ath11k_vif_iter {
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index bc4ae3002322..bfb900d98347 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -7602,6 +7602,189 @@ static int ath11k_start_vdev_delay(struct ieee80211_hw *hw,
return 0;
}
+static u8 ath11k_mac_get_tpe_count(u8 txpwr_intrprt, u8 txpwr_cnt)
+{
+ switch (txpwr_intrprt) {
+ /* Refer "Table 9-276-Meaning of Maximum Transmit Power Count subfield
+ * if the Maximum Transmit Power Interpretation subfield is 0 or 2" of
+ * "IEEE Std 802.11ax 2021".
+ */
+ case IEEE80211_TPE_LOCAL_EIRP:
+ case IEEE80211_TPE_REG_CLIENT_EIRP:
+ txpwr_cnt = txpwr_cnt <= 3 ? txpwr_cnt : 3;
+ txpwr_cnt = txpwr_cnt + 1;
+ break;
+ /* Refer "Table 9-277-Meaning of Maximum Transmit Power Count subfield
+ * if Maximum Transmit Power Interpretation subfield is 1 or 3" of
+ * "IEEE Std 802.11ax 2021".
+ */
+ case IEEE80211_TPE_LOCAL_EIRP_PSD:
+ case IEEE80211_TPE_REG_CLIENT_EIRP_PSD:
+ txpwr_cnt = txpwr_cnt <= 4 ? txpwr_cnt : 4;
+ txpwr_cnt = txpwr_cnt ? (BIT(txpwr_cnt - 1)) : 1;
+ break;
+ }
+
+ return txpwr_cnt;
+}
+
+static u8 ath11k_mac_get_num_pwr_levels(struct cfg80211_chan_def *chan_def)
+{
+ if (chan_def->chan->flags & IEEE80211_CHAN_PSD) {
+ switch (chan_def->width) {
+ case NL80211_CHAN_WIDTH_20:
+ return 1;
+ case NL80211_CHAN_WIDTH_40:
+ return 2;
+ case NL80211_CHAN_WIDTH_80:
+ return 4;
+ case NL80211_CHAN_WIDTH_80P80:
+ case NL80211_CHAN_WIDTH_160:
+ return 8;
+ default:
+ return 1;
+ }
+ } else {
+ switch (chan_def->width) {
+ case NL80211_CHAN_WIDTH_20:
+ return 1;
+ case NL80211_CHAN_WIDTH_40:
+ return 2;
+ case NL80211_CHAN_WIDTH_80:
+ return 3;
+ case NL80211_CHAN_WIDTH_80P80:
+ case NL80211_CHAN_WIDTH_160:
+ return 4;
+ default:
+ return 1;
+ }
+ }
+}
+
+static void ath11k_mac_parse_tx_pwr_env(struct ath11k *ar,
+ struct ieee80211_vif *vif,
+ struct ieee80211_chanctx_conf *ctx)
+{
+ struct ath11k_base *ab = ar->ab;
+ struct ath11k_vif *arvif = (void *)vif->drv_priv;
+ struct ieee80211_bss_conf *bss_conf = &vif->bss_conf;
+ struct ieee80211_tx_pwr_env *single_tpe;
+ enum wmi_reg_6ghz_client_type client_type;
+ struct cur_regulatory_info *reg_info;
+ int i;
+ u8 pwr_count, pwr_interpret, pwr_category;
+ u8 psd_index = 0, non_psd_index = 0, local_tpe_count = 0, reg_tpe_count = 0;
+ bool use_local_tpe, non_psd_set = false, psd_set = false;
+
+ reg_info = &ab->reg_info_store[ar->pdev_idx];
+ client_type = reg_info->client_type;
+
+ for (i = 0; i < bss_conf->tx_pwr_env_num; i++) {
+ single_tpe = &bss_conf->tx_pwr_env[i];
+ pwr_category = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_CATEGORY);
+ pwr_interpret = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_INTERPRET);
+
+ if (pwr_category == client_type) {
+ if (pwr_interpret == IEEE80211_TPE_LOCAL_EIRP ||
+ pwr_interpret == IEEE80211_TPE_LOCAL_EIRP_PSD)
+ local_tpe_count++;
+ else if (pwr_interpret == IEEE80211_TPE_REG_CLIENT_EIRP ||
+ pwr_interpret == IEEE80211_TPE_REG_CLIENT_EIRP_PSD)
+ reg_tpe_count++;
+ }
+ }
+
+ if (!reg_tpe_count && !local_tpe_count) {
+ ath11k_warn(ab,
+ "no transmit power envelope match client power type %d\n",
+ client_type);
+ return;
+ } else if (!reg_tpe_count) {
+ use_local_tpe = true;
+ } else {
+ use_local_tpe = false;
+ }
+
+ for (i = 0; i < bss_conf->tx_pwr_env_num; i++) {
+ single_tpe = &bss_conf->tx_pwr_env[i];
+ pwr_category = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_CATEGORY);
+ pwr_interpret = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_INTERPRET);
+
+ if (pwr_category != client_type)
+ continue;
+
+ /* get local transmit power envelope */
+ if (use_local_tpe) {
+ if (pwr_interpret == IEEE80211_TPE_LOCAL_EIRP) {
+ non_psd_index = i;
+ non_psd_set = true;
+ } else if (pwr_interpret == IEEE80211_TPE_LOCAL_EIRP_PSD) {
+ psd_index = i;
+ psd_set = true;
+ }
+ /* get regulatory transmit power envelope */
+ } else {
+ if (pwr_interpret == IEEE80211_TPE_REG_CLIENT_EIRP) {
+ non_psd_index = i;
+ non_psd_set = true;
+ } else if (pwr_interpret == IEEE80211_TPE_REG_CLIENT_EIRP_PSD) {
+ psd_index = i;
+ psd_set = true;
+ }
+ }
+ }
+
+ if (non_psd_set && !psd_set) {
+ single_tpe = &bss_conf->tx_pwr_env[non_psd_index];
+ pwr_count = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_COUNT);
+ pwr_interpret = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_INTERPRET);
+ arvif->reg_tpc_info.is_psd_power = false;
+ arvif->reg_tpc_info.eirp_power = 0;
+
+ arvif->reg_tpc_info.num_pwr_levels =
+ ath11k_mac_get_tpe_count(pwr_interpret, pwr_count);
+ for (i = 0; i < arvif->reg_tpc_info.num_pwr_levels; i++) {
+ ath11k_dbg(ab, ATH11K_DBG_MAC,
+ "non PSD power[%d] : %d\n",
+ i, single_tpe->tx_power[i]);
+ arvif->reg_tpc_info.tpe[i] = single_tpe->tx_power[i] / 2;
+ }
+ }
+
+ if (psd_set) {
+ single_tpe = &bss_conf->tx_pwr_env[psd_index];
+ pwr_count = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_COUNT);
+ pwr_interpret = u8_get_bits(single_tpe->tx_power_info,
+ IEEE80211_TX_PWR_ENV_INFO_INTERPRET);
+ arvif->reg_tpc_info.is_psd_power = true;
+
+ if (pwr_count == 0) {
+ ath11k_dbg(ab, ATH11K_DBG_MAC,
+ "TPE PSD power : %d\n", single_tpe->tx_power[0]);
+ arvif->reg_tpc_info.num_pwr_levels =
+ ath11k_mac_get_num_pwr_levels(&ctx->def);
+ for (i = 0; i < arvif->reg_tpc_info.num_pwr_levels; i++)
+ arvif->reg_tpc_info.tpe[i] = single_tpe->tx_power[0] / 2;
+ } else {
+ arvif->reg_tpc_info.num_pwr_levels =
+ ath11k_mac_get_tpe_count(pwr_interpret, pwr_count);
+ for (i = 0; i < arvif->reg_tpc_info.num_pwr_levels; i++) {
+ ath11k_dbg(ab, ATH11K_DBG_MAC,
+ "TPE PSD power[%d] : %d\n",
+ i, single_tpe->tx_power[i]);
+ arvif->reg_tpc_info.tpe[i] = single_tpe->tx_power[i] / 2;
+ }
+ }
+ }
+}
+
static int
ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
@@ -7632,6 +7815,8 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
if (power_type == IEEE80211_REG_UNSET_AP)
power_type = IEEE80211_REG_LPI_AP;
ath11k_reg_handle_chan_list(ab, reg_info, power_type);
+
+ ath11k_mac_parse_tx_pwr_env(ar, vif, ctx);
}
/* for QCA6390 bss peer must be created before vdev_start */
--
2.40.1
There are two power types for 6 GHz regulatory, one is AP, another
is client.
When wlan boot up, WMI_REG_CHAN_LIST_CC_EXT_EVENTID is sent from
firmware at an early stage, the interface mode is not decided at
this point, then ath11k select reg rules of AP type as default.
After interface is created, it is exactly decided the interface
type such as AP/mesh point/station. Then ath11k need to update
reg rules to the exact power type matched to the interface type.
The client power type is used for station interface, and AP power
type is used for AP/mesh point interface.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/mac.c | 14 ++++++++++++++
drivers/net/wireless/ath/ath11k/mac.h | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index c071bf5841af..0512c8b0661c 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -6714,6 +6714,12 @@ static int ath11k_mac_vdev_delete(struct ath11k *ar, struct ath11k_vif *arvif)
return ret;
}
+bool ath11k_mac_supports_6ghz_cc_ext(struct ath11k *ar)
+{
+ return (test_bit(WMI_TLV_SERVICE_REG_CC_EXT_EVENT_SUPPORT,
+ ar->ab->wmi_ab.svc_map)) && ar->supports_6ghz;
+}
+
static int ath11k_mac_op_add_interface(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
@@ -6939,6 +6945,14 @@ static int ath11k_mac_op_add_interface(struct ieee80211_hw *hw,
ret);
}
+ if (ath11k_mac_supports_6ghz_cc_ext(ar)) {
+ struct cur_regulatory_info *reg_info;
+
+ reg_info = &ab->reg_info_store[ar->pdev_idx];
+ ath11k_dbg(ab, ATH11K_DBG_MAC, "mac interface added to change reg rules\n");
+ ath11k_reg_handle_chan_list(ab, reg_info, IEEE80211_REG_LPI_AP);
+ }
+
mutex_unlock(&ar->conf_mutex);
return 0;
diff --git a/drivers/net/wireless/ath/ath11k/mac.h b/drivers/net/wireless/ath/ath11k/mac.h
index e4835e0b7998..94c5c61ae2bb 100644
--- a/drivers/net/wireless/ath/ath11k/mac.h
+++ b/drivers/net/wireless/ath/ath11k/mac.h
@@ -155,7 +155,7 @@ struct ath11k_vif *ath11k_mac_get_arvif_by_vdev_id(struct ath11k_base *ab,
u8 ath11k_mac_get_target_pdev_id(struct ath11k *ar);
u8 ath11k_mac_get_target_pdev_id_from_vif(struct ath11k_vif *arvif);
struct ath11k_vif *ath11k_mac_get_vif_up(struct ath11k_base *ab);
-
+bool ath11k_mac_supports_6ghz_cc_ext(struct ath11k *ar);
struct ath11k *ath11k_mac_get_ar_by_vdev_id(struct ath11k_base *ab, u32 vdev_id);
struct ath11k *ath11k_mac_get_ar_by_pdev_id(struct ath11k_base *ab, u32 pdev_id);
void ath11k_mac_drain_tx(struct ath11k *ar);
--
2.40.1
When station is connected to a 6 GHz AP, it has 2 way to configure
the power limit to firmware. The first way is to send 2 wmi command
WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
firmware which include more parameters for power control.
The first way is disabled in previous patch
"ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6 GHz".
Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
send the firmware after vdev start response success from firmware, it
is for the second way of power control.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index a8ae281d2635..f8b907a758b1 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct ath11k_vif *arvif,
return ret;
}
+ if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
+ ath11k_mac_fill_reg_tpc_info(ar, arvif->vif, &arvif->chanctx);
+ ath11k_wmi_send_vdev_set_tpc_power(ar, arvif->vdev_id,
+ &arvif->reg_tpc_info);
+ }
+
if (!restart)
ar->num_started_vdevs++;
@@ -8108,7 +8114,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
if (power_type == IEEE80211_REG_UNSET_AP)
power_type = IEEE80211_REG_LPI_AP;
ath11k_reg_handle_chan_list(ab, reg_info, power_type);
-
+ arvif->chanctx = *ctx;
ath11k_mac_parse_tx_pwr_env(ar, vif, ctx);
}
--
2.40.1
When station connect to AP on 6 GHz band, it needs switch the regulatory
rules according to the regulatory info sub field in HE operation element.
Switch to the power type which AP used for station interface.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/mac.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 0512c8b0661c..bc4ae3002322 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -7613,6 +7613,8 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
struct ath11k_vif *arvif = ath11k_vif_to_arvif(vif);
int ret;
struct peer_create_params param;
+ struct cur_regulatory_info *reg_info;
+ enum ieee80211_ap_reg_power power_type;
mutex_lock(&ar->conf_mutex);
@@ -7620,6 +7622,18 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
"chanctx assign ptr %p vdev_id %i\n",
ctx, arvif->vdev_id);
+ if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
+ ctx->def.chan->band == NL80211_BAND_6GHZ &&
+ arvif->vdev_type == WMI_VDEV_TYPE_STA) {
+ reg_info = &ab->reg_info_store[ar->pdev_idx];
+ power_type = vif->bss_conf.power_type;
+ ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n",
+ power_type);
+ if (power_type == IEEE80211_REG_UNSET_AP)
+ power_type = IEEE80211_REG_LPI_AP;
+ ath11k_reg_handle_chan_list(ab, reg_info, power_type);
+ }
+
/* for QCA6390 bss peer must be created before vdev_start */
if (ab->hw_params.vdev_start_delay &&
arvif->vdev_type != WMI_VDEV_TYPE_AP &&
--
2.40.1
Prepare the parameters which is needed for WMI command WMI_VDEV_SET_TPC_POWER_CMDID.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/mac.c | 277 ++++++++++++++++++++++++++
drivers/net/wireless/ath/ath11k/mac.h | 3 +
2 files changed, 280 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index bfb900d98347..f05d66913abd 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -7661,6 +7661,283 @@ static u8 ath11k_mac_get_num_pwr_levels(struct cfg80211_chan_def *chan_def)
}
}
+static u16 ath11k_mac_get_6ghz_start_frequency(struct cfg80211_chan_def *chan_def)
+{
+ u16 diff_seq;
+
+ /* It is to get the lowest channel number's center frequency of the chan.
+ * For example,
+ * bandwidth=40 MHz, center frequency is 5965, lowest channel is 1
+ * with center frequency 5955, its diff is 5965 - 5955 = 10.
+ * bandwidth=80 MHz, center frequency is 5985, lowest channel is 1
+ * with center frequency 5955, its diff is 5985 - 5955 = 30.
+ * bandwidth=160 MHz, center frequency is 6025, lowest channel is 1
+ * with center frequency 5955, its diff is 6025 - 5955 = 70.
+ */
+ switch (chan_def->width) {
+ case NL80211_CHAN_WIDTH_160:
+ diff_seq = 70;
+ break;
+ case NL80211_CHAN_WIDTH_80:
+ case NL80211_CHAN_WIDTH_80P80:
+ diff_seq = 30;
+ break;
+ case NL80211_CHAN_WIDTH_40:
+ diff_seq = 10;
+ break;
+ default:
+ diff_seq = 0;
+ }
+
+ return chan_def->center_freq1 - diff_seq;
+}
+
+static u16 ath11k_mac_get_seg_freq(struct cfg80211_chan_def *chan_def,
+ u16 start_seq, u8 seq)
+{
+ u16 seg_seq;
+
+ /* It is to get the center frequency of the specific bandwidth.
+ * start_seq means the lowest channel number's center frequency.
+ * seq 0/1/2/3 means 20 MHz/40 MHz/80 MHz/160 MHz&80P80.
+ * For example,
+ * lowest channel is 1, its center frequency 5955,
+ * center frequency is 5955 when bandwidth=20 MHz, its diff is 5955 - 5955 = 0.
+ * lowest channel is 1, its center frequency 5955,
+ * center frequency is 5965 when bandwidth=40 MHz, its diff is 5965 - 5955 = 10.
+ * lowest channel is 1, its center frequency 5955,
+ * center frequency is 5985 when bandwidth=80 MHz, its diff is 5985 - 5955 = 30.
+ * lowest channel is 1, its center frequency 5955,
+ * center frequency is 6025 when bandwidth=160 MHz, its diff is 6025 - 5955 = 70.
+ */
+ if (chan_def->width == NL80211_CHAN_WIDTH_80P80 && seq == 3)
+ return chan_def->center_freq2;
+
+ seg_seq = 10 * (BIT(seq) - 1);
+ return seg_seq + start_seq;
+}
+
+static void ath11k_mac_get_psd_channel(struct ath11k *ar,
+ u16 step_freq,
+ u16 *start_freq,
+ u16 *center_freq,
+ u8 i,
+ struct ieee80211_channel **temp_chan,
+ s8 *tx_power)
+{
+ /* It is to get the the center frequency for each 20 MHz.
+ * For example, if the chan is 160 MHz and center frequency is 6025,
+ * then it include 8 channels, they are 1/5/9/13/17/21/25/29,
+ * channel number 1's center frequency is 5955, it is parameter start_freq.
+ * parameter i is the step of the 8 channels. i is 0~7 for the 8 channels.
+ * the channel 1/5/9/13/17/21/25/29 maps i=0/1/2/3/4/5/6/7,
+ * and maps its center frequency is 5955/5975/5995/6015/6035/6055/6075/6095,
+ * the gap is 20 for each channel, parameter step_freq means the gap.
+ * after get the center frequency of each channel, it is easy to find the
+ * struct ieee80211_channel of it and get the max_reg_power.
+ */
+ *center_freq = *start_freq + i * step_freq;
+ *temp_chan = ieee80211_get_channel(ar->hw->wiphy, *center_freq);
+ *tx_power = (*temp_chan)->max_reg_power;
+}
+
+static void ath11k_mac_get_eirp_power(struct ath11k *ar,
+ u16 *start_freq,
+ u16 *center_freq,
+ u8 i,
+ struct ieee80211_channel **temp_chan,
+ struct cfg80211_chan_def *def,
+ s8 *tx_power)
+{
+ /* It is to get the the center frequency for 20 MHz/40 MHz/80 MHz/
+ * 160 MHz&80P80 bandwidth, and then plus 10 to the center frequency,
+ * it is the center frequency of a channel number.
+ * For example, when configured channel number is 1.
+ * center frequency is 5965 when bandwidth=40 MHz, after plus 10, it is 5975,
+ * then it is channel number 5.
+ * center frequency is 5985 when bandwidth=80 MHz, after plus 10, it is 5995,
+ * then it is channel number 9.
+ * center frequency is 6025 when bandwidth=160 MHz, after plus 10, it is 6035,
+ * then it is channel number 17.
+ * after get the center frequency of each channel, it is easy to find the
+ * struct ieee80211_channel of it and get the max_reg_power.
+ */
+ *center_freq = ath11k_mac_get_seg_freq(def, *start_freq, i);
+
+ /* For the 20 MHz, its center frequency is same with same channel */
+ if (i != 0)
+ *center_freq += 10;
+
+ *temp_chan = ieee80211_get_channel(ar->hw->wiphy, *center_freq);
+ *tx_power = (*temp_chan)->max_reg_power;
+}
+
+void ath11k_mac_fill_reg_tpc_info(struct ath11k *ar,
+ struct ieee80211_vif *vif,
+ struct ieee80211_chanctx_conf *ctx)
+{
+ struct ath11k_base *ab = ar->ab;
+ struct ath11k_vif *arvif = (void *)vif->drv_priv;
+ struct ieee80211_bss_conf *bss_conf = &vif->bss_conf;
+ struct ath11k_reg_tpc_power_info *reg_tpc_info = &arvif->reg_tpc_info;
+ struct ieee80211_channel *chan, *temp_chan;
+ u8 pwr_lvl_idx, num_pwr_levels, pwr_reduction;
+ bool is_psd_power = false, is_tpe_present = false;
+ s8 max_tx_power[IEEE80211_MAX_NUM_PWR_LEVEL],
+ psd_power, tx_power, eirp_power;
+ u16 oper_freq, start_freq, center_freq;
+
+ chan = ctx->def.chan;
+ oper_freq = ctx->def.chan->center_freq;
+ start_freq = ath11k_mac_get_6ghz_start_frequency(&ctx->def);
+ pwr_reduction = bss_conf->pwr_reduction;
+
+ if (arvif->reg_tpc_info.num_pwr_levels) {
+ is_tpe_present = true;
+ num_pwr_levels = arvif->reg_tpc_info.num_pwr_levels;
+ } else {
+ num_pwr_levels = ath11k_mac_get_num_pwr_levels(&ctx->def);
+ }
+
+ for (pwr_lvl_idx = 0; pwr_lvl_idx < num_pwr_levels; pwr_lvl_idx++) {
+ /* STA received TPE IE*/
+ if (is_tpe_present) {
+ /* local power is PSD power*/
+ if (chan->flags & IEEE80211_CHAN_PSD) {
+ /* Connecting AP is psd power */
+ if (reg_tpc_info->is_psd_power) {
+ is_psd_power = true;
+ ath11k_mac_get_psd_channel(ar, 20,
+ &start_freq,
+ ¢er_freq,
+ pwr_lvl_idx,
+ &temp_chan,
+ &tx_power);
+ psd_power = temp_chan->psd;
+ eirp_power = tx_power;
+ max_tx_power[pwr_lvl_idx] =
+ min_t(s8,
+ psd_power,
+ reg_tpc_info->tpe[pwr_lvl_idx]);
+ /* Connecting AP is not psd power */
+ } else {
+ ath11k_mac_get_eirp_power(ar,
+ &start_freq,
+ ¢er_freq,
+ pwr_lvl_idx,
+ &temp_chan,
+ &ctx->def,
+ &tx_power);
+ psd_power = temp_chan->psd;
+ /* convert psd power to EIRP power based
+ * on channel width
+ */
+ tx_power =
+ min_t(s8, tx_power,
+ psd_power + 13 + pwr_lvl_idx * 3);
+ max_tx_power[pwr_lvl_idx] =
+ min_t(s8,
+ tx_power,
+ reg_tpc_info->tpe[pwr_lvl_idx]);
+ }
+ /* local power is not PSD power */
+ } else {
+ /* Connecting AP is psd power */
+ if (reg_tpc_info->is_psd_power) {
+ is_psd_power = true;
+ ath11k_mac_get_psd_channel(ar, 20,
+ &start_freq,
+ ¢er_freq,
+ pwr_lvl_idx,
+ &temp_chan,
+ &tx_power);
+ eirp_power = tx_power;
+ max_tx_power[pwr_lvl_idx] =
+ reg_tpc_info->tpe[pwr_lvl_idx];
+ /* Connecting AP is not psd power */
+ } else {
+ ath11k_mac_get_eirp_power(ar,
+ &start_freq,
+ ¢er_freq,
+ pwr_lvl_idx,
+ &temp_chan,
+ &ctx->def,
+ &tx_power);
+ max_tx_power[pwr_lvl_idx] =
+ min_t(s8,
+ tx_power,
+ reg_tpc_info->tpe[pwr_lvl_idx]);
+ }
+ }
+ /* STA not received TPE IE */
+ } else {
+ /* local power is PSD power*/
+ if (chan->flags & IEEE80211_CHAN_PSD) {
+ is_psd_power = true;
+ ath11k_mac_get_psd_channel(ar, 20,
+ &start_freq,
+ ¢er_freq,
+ pwr_lvl_idx,
+ &temp_chan,
+ &tx_power);
+ psd_power = temp_chan->psd;
+ eirp_power = tx_power;
+ max_tx_power[pwr_lvl_idx] = psd_power;
+ } else {
+ ath11k_mac_get_eirp_power(ar,
+ &start_freq,
+ ¢er_freq,
+ pwr_lvl_idx,
+ &temp_chan,
+ &ctx->def,
+ &tx_power);
+ max_tx_power[pwr_lvl_idx] = tx_power;
+ }
+ }
+
+ if (is_psd_power) {
+ /* If AP local power constraint is present */
+ if (pwr_reduction)
+ eirp_power = eirp_power - pwr_reduction;
+
+ /* If firmware updated max tx power is non zero, then take
+ * the min of firmware updated ap tx power
+ * and max power derived from above mentioned parameters.
+ */
+ ath11k_dbg(ab, ATH11K_DBG_MAC,
+ "eirp power : %d firmware report power : %d\n",
+ eirp_power, ar->max_allowed_tx_power);
+ if (ar->max_allowed_tx_power)
+ eirp_power = min_t(s8,
+ eirp_power,
+ ar->max_allowed_tx_power);
+ } else {
+ /* If AP local power constraint is present */
+ if (pwr_reduction)
+ max_tx_power[pwr_lvl_idx] =
+ max_tx_power[pwr_lvl_idx] - pwr_reduction;
+ /* If firmware updated max tx power is non zero, then take
+ * the min of firmware updated ap tx power
+ * and max power derived from above mentioned parameters.
+ */
+ if (ar->max_allowed_tx_power)
+ max_tx_power[pwr_lvl_idx] =
+ min_t(s8,
+ max_tx_power[pwr_lvl_idx],
+ ar->max_allowed_tx_power);
+ }
+ reg_tpc_info->chan_power_info[pwr_lvl_idx].chan_cfreq = center_freq;
+ reg_tpc_info->chan_power_info[pwr_lvl_idx].tx_power =
+ max_tx_power[pwr_lvl_idx];
+ }
+
+ reg_tpc_info->num_pwr_levels = num_pwr_levels;
+ reg_tpc_info->is_psd_power = is_psd_power;
+ reg_tpc_info->eirp_power = eirp_power;
+ reg_tpc_info->ap_power_type =
+ ath11k_reg_ap_pwr_convert(vif->bss_conf.power_type);
+}
+
static void ath11k_mac_parse_tx_pwr_env(struct ath11k *ar,
struct ieee80211_vif *vif,
struct ieee80211_chanctx_conf *ctx)
diff --git a/drivers/net/wireless/ath/ath11k/mac.h b/drivers/net/wireless/ath/ath11k/mac.h
index 94c5c61ae2bb..25c18be75f46 100644
--- a/drivers/net/wireless/ath/ath11k/mac.h
+++ b/drivers/net/wireless/ath/ath11k/mac.h
@@ -174,4 +174,7 @@ int ath11k_mac_wait_tx_complete(struct ath11k *ar);
int ath11k_mac_vif_set_keepalive(struct ath11k_vif *arvif,
enum wmi_sta_keepalive_method method,
u32 interval);
+void ath11k_mac_fill_reg_tpc_info(struct ath11k *ar,
+ struct ieee80211_vif *vif,
+ struct ieee80211_chanctx_conf *ctx);
#endif
--
2.40.1
When station is connected to a 6 GHz AP, it has 2 way to configure
the power limit to firmware. The first way is to send 2 wmi command
WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
firmware which include more parameters for power control.
When firmware support SERVICE_EXT_TPC_REG, it means firmware support
the second way for WMI_VDEV_SET_TPC_POWER_CMDID, then ath11k discard
BSS_CHANGED_TXPOWER flag from mac80211 which is used to the first way
for 6 GHz band in this patch and select the second way in the subsequent
patch.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/mac.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index f05d66913abd..a8ae281d2635 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -3396,6 +3396,18 @@ static int ath11k_mac_config_obss_pd(struct ath11k *ar,
return 0;
}
+static bool ath11k_mac_supports_station_tpc(struct ath11k *ar,
+ struct ath11k_vif *arvif,
+ const struct cfg80211_chan_def *chandef)
+{
+ return ath11k_mac_supports_6ghz_cc_ext(ar) &&
+ test_bit(WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT, ar->ab->wmi_ab.svc_map) &&
+ arvif->vdev_type == WMI_VDEV_TYPE_STA &&
+ arvif->vdev_subtype == WMI_VDEV_SUBTYPE_NONE &&
+ chandef->chan &&
+ chandef->chan->band == NL80211_BAND_6GHZ;
+}
+
static void ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
@@ -3595,9 +3607,13 @@ static void ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_TXPOWER) {
ath11k_dbg(ar->ab, ATH11K_DBG_MAC, "vdev_id %i txpower %d\n",
arvif->vdev_id, info->txpower);
-
- arvif->txpower = info->txpower;
- ath11k_mac_txpower_recalc(ar);
+ if (ath11k_mac_supports_station_tpc(ar, arvif, &info->chandef)) {
+ ath11k_dbg(ar->ab, ATH11K_DBG_MAC,
+ "discard tx power, change to set TPC power\n");
+ } else {
+ arvif->txpower = info->txpower;
+ ath11k_mac_txpower_recalc(ar);
+ }
}
if (changed & BSS_CHANGED_PS &&
--
2.40.1
The regulatory info of WMI_REG_CHAN_LIST_CC_EXT_EVENTID is not saved
in ath11k now, the info should be saved in ath11k. Save the info for
each radio and support switch regulatory rules dynamically.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Wen Gong <[email protected]>
---
drivers/net/wireless/ath/ath11k/core.h | 1 +
drivers/net/wireless/ath/ath11k/mac.h | 1 -
drivers/net/wireless/ath/ath11k/reg.c | 6 ++
drivers/net/wireless/ath/ath11k/wmi.c | 141 ++++++++++++++++++-------
drivers/net/wireless/ath/ath11k/wmi.h | 5 +
5 files changed, 113 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/ath/ath11k/core.h
index b04447762483..9fbe4f67218c 100644
--- a/drivers/net/wireless/ath/ath11k/core.h
+++ b/drivers/net/wireless/ath/ath11k/core.h
@@ -923,6 +923,7 @@ struct ath11k_base {
* This may or may not be used during the runtime
*/
struct ieee80211_regdomain *new_regd[MAX_RADIOS];
+ struct cur_regulatory_info *reg_info_store;
/* Current DFS Regulatory */
enum ath11k_dfs_region dfs_region;
diff --git a/drivers/net/wireless/ath/ath11k/mac.h b/drivers/net/wireless/ath/ath11k/mac.h
index 0231783ad754..e4835e0b7998 100644
--- a/drivers/net/wireless/ath/ath11k/mac.h
+++ b/drivers/net/wireless/ath/ath11k/mac.h
@@ -158,7 +158,6 @@ struct ath11k_vif *ath11k_mac_get_vif_up(struct ath11k_base *ab);
struct ath11k *ath11k_mac_get_ar_by_vdev_id(struct ath11k_base *ab, u32 vdev_id);
struct ath11k *ath11k_mac_get_ar_by_pdev_id(struct ath11k_base *ab, u32 pdev_id);
-
void ath11k_mac_drain_tx(struct ath11k *ar);
void ath11k_mac_peer_cleanup_all(struct ath11k *ar);
int ath11k_mac_tx_mgmt_pending_free(int buf_id, void *skb, void *ctx);
diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/ath/ath11k/reg.c
index 2a3edb60c08f..0535ab8a28fa 100644
--- a/drivers/net/wireless/ath/ath11k/reg.c
+++ b/drivers/net/wireless/ath/ath11k/reg.c
@@ -809,6 +809,12 @@ void ath11k_reg_free(struct ath11k_base *ab)
{
int i;
+ for (i = 0; i < ab->num_radios; i++)
+ ath11k_reg_reset_info(&ab->reg_info_store[i]);
+
+ kfree(ab->reg_info_store);
+ ab->reg_info_store = NULL;
+
for (i = 0; i < ab->hw_params.max_radios; i++) {
kfree(ab->default_regd[i]);
kfree(ab->new_regd[i]);
diff --git a/drivers/net/wireless/ath/ath11k/wmi.c b/drivers/net/wireless/ath/ath11k/wmi.c
index 5a6578865b25..1fb445106872 100644
--- a/drivers/net/wireless/ath/ath11k/wmi.c
+++ b/drivers/net/wireless/ath/ath11k/wmi.c
@@ -4749,6 +4749,11 @@ static int ath11k_wmi_tlv_ext_soc_hal_reg_caps_parse(struct ath11k_base *soc,
soc->pdevs[0].pdev_id = 0;
}
+ if (!soc->reg_info_store)
+ soc->reg_info_store = kcalloc(soc->num_radios,
+ sizeof(*soc->reg_info_store),
+ GFP_ATOMIC);
+
return 0;
}
@@ -7070,33 +7075,54 @@ static bool ath11k_reg_is_world_alpha(char *alpha)
return false;
}
-static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
- struct sk_buff *skb,
- enum wmi_reg_chan_list_cmd_type id)
+void ath11k_reg_reset_info(struct cur_regulatory_info *reg_info)
{
- struct cur_regulatory_info *reg_info = NULL;
- struct ieee80211_regdomain *regd = NULL;
- bool intersect = false;
- int ret = 0, pdev_idx, i, j;
- struct ath11k *ar;
+ int i, j;
- reg_info = kzalloc(sizeof(*reg_info), GFP_ATOMIC);
- if (!reg_info) {
- ret = -ENOMEM;
- goto fallback;
- }
+ if (reg_info) {
+ kfree(reg_info->reg_rules_2ghz_ptr);
- if (id == WMI_REG_CHAN_LIST_CC_ID)
- ret = ath11k_pull_reg_chan_list_update_ev(ab, skb, reg_info);
- else
- ret = ath11k_pull_reg_chan_list_ext_update_ev(ab, skb, reg_info);
+ kfree(reg_info->reg_rules_5ghz_ptr);
- if (ret) {
- ath11k_warn(ab, "failed to extract regulatory info from received event\n");
- goto fallback;
+ for (i = 0; i < WMI_REG_CURRENT_MAX_AP_TYPE; i++) {
+ kfree(reg_info->reg_rules_6ghz_ap_ptr[i]);
+ for (j = 0; j < WMI_REG_MAX_CLIENT_TYPE; j++)
+ kfree(reg_info->reg_rules_6ghz_client_ptr[i][j]);
+ }
+
+ memset(reg_info, 0, sizeof(*reg_info));
}
+}
+
+static
+enum wmi_vdev_type ath11k_reg_get_ar_vdev_type(struct ath11k *ar)
+{
+ struct ath11k_vif *arvif;
+
+ /* Currently each struct ath11k maps to one struct ieee80211_hw/wiphy
+ * and one struct ieee80211_regdomain, so it could only store one group
+ * reg rules. It means muti-interface concurrency in the same ath11k is
+ * not support for the regdomain. So get the vdev type of the first entry
+ * now. After concurrency support for the regdomain, this should change.
+ */
+ arvif = list_first_entry_or_null(&ar->arvifs, struct ath11k_vif, list);
+ if (arvif)
+ return arvif->vdev_type;
+
+ return WMI_VDEV_TYPE_UNSPEC;
+}
- ath11k_dbg(ab, ATH11K_DBG_WMI, "event reg chan list id %d", id);
+int ath11k_reg_handle_chan_list(struct ath11k_base *ab,
+ struct cur_regulatory_info *reg_info,
+ enum ieee80211_ap_reg_power power_type)
+{
+ struct ieee80211_regdomain *regd;
+ bool intersect = false;
+ int pdev_idx;
+ struct ath11k *ar;
+ enum wmi_vdev_type vdev_type;
+
+ ath11k_dbg(ab, ATH11K_DBG_WMI, "event reg handle chan list");
if (reg_info->status_code != REG_SET_CC_STATUS_PASS) {
/* In case of failure to set the requested ctry,
@@ -7104,7 +7130,7 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
* and return from here.
*/
ath11k_warn(ab, "Failed to set the requested Country regulatory setting\n");
- goto mem_free;
+ return -EINVAL;
}
pdev_idx = reg_info->phy_id;
@@ -7116,7 +7142,7 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
if (test_bit(ATH11K_FLAG_RECOVERY, &ab->dev_flags) &&
ab->default_regd[pdev_idx]) {
spin_unlock(&ab->base_lock);
- goto mem_free;
+ goto retfail;
}
spin_unlock(&ab->base_lock);
@@ -7127,7 +7153,7 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
*/
if (ab->hw_params.single_pdev_only &&
pdev_idx < ab->hw_params.num_rxmda_per_pdev)
- goto mem_free;
+ return 0;
else
goto fallback;
}
@@ -7138,7 +7164,7 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
if (ab->default_regd[pdev_idx] && !ab->new_regd[pdev_idx] &&
!memcmp((char *)ab->default_regd[pdev_idx]->alpha2,
(char *)reg_info->alpha2, 2))
- goto mem_free;
+ goto retfail;
/* Intersect new rules with default regd if a new country setting was
* requested, i.e a default regd was already set during initialization
@@ -7150,13 +7176,24 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
!ath11k_reg_is_world_alpha((char *)reg_info->alpha2))
intersect = true;
- regd = ath11k_reg_build_regd(ab, reg_info, intersect,
- WMI_VDEV_TYPE_AP, IEEE80211_REG_LPI_AP);
+ ar = ab->pdevs[pdev_idx].ar;
+ vdev_type = ath11k_reg_get_ar_vdev_type(ar);
+
+ ath11k_dbg(ab, ATH11K_DBG_WMI,
+ "wmi handle chan list power type %d vdev type %d intersect %d\n",
+ power_type, vdev_type, intersect);
+
+ regd = ath11k_reg_build_regd(ab, reg_info, intersect, vdev_type, power_type);
if (!regd) {
ath11k_warn(ab, "failed to build regd from reg_info\n");
goto fallback;
}
+ if (power_type == IEEE80211_REG_UNSET_AP) {
+ ath11k_reg_reset_info(&ab->reg_info_store[pdev_idx]);
+ ab->reg_info_store[pdev_idx] = *reg_info;
+ }
+
spin_lock(&ab->base_lock);
if (ab->default_regd[pdev_idx]) {
/* The initial rules from FW after WMI Init is to build
@@ -7179,7 +7216,7 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
ab->dfs_region = reg_info->dfs_region;
spin_unlock(&ab->base_lock);
- goto mem_free;
+ return 0;
fallback:
/* Fallback to older reg (by sending previous country setting
@@ -7191,20 +7228,44 @@ static int ath11k_reg_chan_list_event(struct ath11k_base *ab,
*/
/* TODO: This is rare, but still should also be handled */
WARN_ON(1);
-mem_free:
- if (reg_info) {
- kfree(reg_info->reg_rules_2ghz_ptr);
- kfree(reg_info->reg_rules_5ghz_ptr);
- if (reg_info->is_ext_reg_event) {
- for (i = 0; i < WMI_REG_CURRENT_MAX_AP_TYPE; i++)
- kfree(reg_info->reg_rules_6ghz_ap_ptr[i]);
- for (j = 0; j < WMI_REG_CURRENT_MAX_AP_TYPE; j++)
- for (i = 0; i < WMI_REG_MAX_CLIENT_TYPE; i++)
- kfree(reg_info->reg_rules_6ghz_client_ptr[j][i]);
- }
- kfree(reg_info);
+retfail:
+
+ return -EINVAL;
+}
+
+static int ath11k_reg_chan_list_event(struct ath11k_base *ab, struct sk_buff *skb,
+ enum wmi_reg_chan_list_cmd_type id)
+{
+ struct cur_regulatory_info *reg_info;
+ int ret;
+
+ reg_info = kzalloc(sizeof(*reg_info), GFP_ATOMIC);
+ if (!reg_info)
+ return -ENOMEM;
+
+ if (id == WMI_REG_CHAN_LIST_CC_ID)
+ ret = ath11k_pull_reg_chan_list_update_ev(ab, skb, reg_info);
+ else
+ ret = ath11k_pull_reg_chan_list_ext_update_ev(ab, skb, reg_info);
+
+ if (ret) {
+ ath11k_warn(ab, "failed to extract regulatory info\n");
+ goto mem_free;
}
+
+ ret = ath11k_reg_handle_chan_list(ab, reg_info, IEEE80211_REG_UNSET_AP);
+ if (ret) {
+ ath11k_warn(ab, "failed to process regulatory info %d\n", ret);
+ goto mem_free;
+ }
+
+ kfree(reg_info);
+ return 0;
+
+mem_free:
+ ath11k_reg_reset_info(reg_info);
+ kfree(reg_info);
return ret;
}
diff --git a/drivers/net/wireless/ath/ath11k/wmi.h b/drivers/net/wireless/ath/ath11k/wmi.h
index 100bb816b592..a34a04bd4612 100644
--- a/drivers/net/wireless/ath/ath11k/wmi.h
+++ b/drivers/net/wireless/ath/ath11k/wmi.h
@@ -4975,6 +4975,7 @@ struct ath11k_targ_cap {
};
enum wmi_vdev_type {
+ WMI_VDEV_TYPE_UNSPEC = 0,
WMI_VDEV_TYPE_AP = 1,
WMI_VDEV_TYPE_STA = 2,
WMI_VDEV_TYPE_IBSS = 3,
@@ -6505,4 +6506,8 @@ int ath11k_wmi_pdev_set_bios_geo_table_param(struct ath11k *ar);
int ath11k_wmi_sta_keepalive(struct ath11k *ar,
const struct wmi_sta_keepalive_arg *arg);
+void ath11k_reg_reset_info(struct cur_regulatory_info *reg_info);
+int ath11k_reg_handle_chan_list(struct ath11k_base *ab,
+ struct cur_regulatory_info *reg_info,
+ enum ieee80211_ap_reg_power power_type);
#endif
--
2.40.1
On 9/20/2023 1:23 AM, Wen Gong wrote:
> When station is connected to a 6 GHz AP, it has 2 way to configure
> the power limit to firmware. The first way is to send 2 wmi command
> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
> firmware which include more parameters for power control.
>
> The first way is disabled in previous patch
> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6 GHz".
>
> Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
> send the firmware after vdev start response success from firmware, it
> is for the second way of power control.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
As previously mentioned I'd squash this with patch 11
On 9/20/2023 1:23 AM, Wen Gong wrote:
> There are two power types for 6 GHz regulatory, one is AP, another
> is client.
>
> When wlan boot up, WMI_REG_CHAN_LIST_CC_EXT_EVENTID is sent from
> firmware at an early stage, the interface mode is not decided at
> this point, then ath11k select reg rules of AP type as default.
>
> After interface is created, it is exactly decided the interface
> type such as AP/mesh point/station. Then ath11k need to update
> reg rules to the exact power type matched to the interface type.
>
> The client power type is used for station interface, and AP power
> type is used for AP/mesh point interface.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
On 9/20/2023 1:23 AM, Wen Gong wrote:
> The transmit power envelope element has some fields for power, ath11k
> should parse it according to IEEE Std 802.11ax™‐2021.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
On 9/20/2023 1:23 AM, Wen Gong wrote:
> The regulatory info of WMI_REG_CHAN_LIST_CC_EXT_EVENTID is not saved
> in ath11k now, the info should be saved in ath11k. Save the info for
> each radio and support switch regulatory rules dynamically
Kalle, can you add hard stop when you apply to pending?
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
On 9/20/2023 1:23 AM, Wen Gong wrote:
> Prepare the parameters which is needed for WMI command WMI_VDEV_SET_TPC_POWER_CMDID.
Kalle, can you s/is/are/ when you pull into pending?
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
(but I have a non-blocking comments I'll post separately)
On 9/22/2023 5:04 PM, Aditya Kumar Singh wrote:
> On 9/20/23 13:53, Wen Gong wrote:
>>
[...]
>> @@ -3595,9 +3607,13 @@ static void
>> ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
>> if (changed & BSS_CHANGED_TXPOWER) {
>> ath11k_dbg(ar->ab, ATH11K_DBG_MAC, "vdev_id %i txpower %d\n",
>> arvif->vdev_id, info->txpower);
>> -
>> - arvif->txpower = info->txpower;
>> - ath11k_mac_txpower_recalc(ar);
>> + if (ath11k_mac_supports_station_tpc(ar, arvif,
>> &info->chandef)) {
> So even if user wants to operate in low power value, we won't be
> allowing to do that in case of 6 GHz station mode? Only TPC power is
> valid?
>
You are right. I think I will drop this patch. Firmware will select the
lowest TX power from multi-source.
>> + ath11k_dbg(ar->ab, ATH11K_DBG_MAC,
>> + "discard tx power, change to set TPC power\n");
>> + } else {
>> + arvif->txpower = info->txpower;
>> + ath11k_mac_txpower_recalc(ar);
>> + }
>> }
>> if (changed & BSS_CHANGED_PS &&
>
>
On 9/20/23 13:53, Wen Gong wrote:
> + if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
> + ctx->def.chan->band == NL80211_BAND_6GHZ &&
> + arvif->vdev_type == WMI_VDEV_TYPE_STA) {
> + reg_info = &ab->reg_info_store[ar->pdev_idx];
> + power_type = vif->bss_conf.power_type;
> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n",
> + power_type);
> + if (power_type == IEEE80211_REG_UNSET_AP)
> + power_type = IEEE80211_REG_LPI_AP;
Why having _UNSET_ power type in vif->bss_conf.power_type is fine?
Typically, during association, we would be setting this from the
beacon/association response frame's HE 6 GHz Operation Info Field. So is
it fine if the field is carrying some info which we don't know (or may
be don't support it yet)? Why are we masking it with _LPI_ mode?
Also, I see that currently mac80211 only sets LPI or SP. So let's say
STA is trying to connect to VLP AP, mac80211 will set it as _UNSET_. And
then here, we will be treating it as LPI AP. Is that fine?
On 9/22/2023 5:24 PM, Aditya Kumar Singh wrote:
> On 9/20/23 13:53, Wen Gong wrote:
>> When station is connected to a 6 GHz AP, it has 2 way to configure
>> the power limit to firmware. The first way is to send 2 wmi command
>> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
>> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
>> firmware which include more parameters for power control.
>>
>> The first way is disabled in previous patch
>> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6
>> GHz".
>>
>> Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
>> send the firmware after vdev start response success from firmware, it
>> is for the second way of power control.
>>
>> Tested-on: WCN6855 hw2.0 PCI
>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>>
>> Signed-off-by: Wen Gong <[email protected]>
>> ---
>> drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
>> b/drivers/net/wireless/ath/ath11k/mac.c
>> index a8ae281d2635..f8b907a758b1 100644
>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>> @@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct
>> ath11k_vif *arvif,
>> return ret;
>> }
>> + if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
>> + ath11k_mac_fill_reg_tpc_info(ar, arvif->vif, &arvif->chanctx);
> So we are passing local copy of channel context stored in
> arvif->chanctx. Do we need to update it when channel changes?
>
> I see that during assignment time, we are copying/updating it and
> accordingly the command will be sent to firmware, but what about when
> STA moves channel? arvif->chanctx should be updated and tpc command
> should be sent again in that case?
This has been discussed before here per question of Johannes:"Could this
information change? Should we track it in beacons?":
[PATCH 9/9] mac80211: save transmit power envelope element and power
constraint
https://lore.kernel.org/linux-wireless/[email protected]/
>
>> + ath11k_wmi_send_vdev_set_tpc_power(ar, arvif->vdev_id,
>> + &arvif->reg_tpc_info);
>> + }
>> +
>> if (!restart)
>> ar->num_started_vdevs++;
>> @@ -8108,7 +8114,7 @@ ath11k_mac_op_assign_vif_chanctx(struct
>> ieee80211_hw *hw,
>> if (power_type == IEEE80211_REG_UNSET_AP)
>> power_type = IEEE80211_REG_LPI_AP;
>> ath11k_reg_handle_chan_list(ab, reg_info, power_type);
>> -
>> + arvif->chanctx = *ctx;
>> ath11k_mac_parse_tx_pwr_env(ar, vif, ctx);
>> }
On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote:
> On 9/20/23 13:53, Wen Gong wrote:
>
>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
>> + ctx->def.chan->band == NL80211_BAND_6GHZ &&
>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) {
>> + reg_info = &ab->reg_info_store[ar->pdev_idx];
>> + power_type = vif->bss_conf.power_type;
>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n",
>> + power_type);
>> + if (power_type == IEEE80211_REG_UNSET_AP)
>> + power_type = IEEE80211_REG_LPI_AP;
> Why having _UNSET_ power type in vif->bss_conf.power_type is fine?
> Typically, during association, we would be setting this from the
> beacon/association response frame's HE 6 GHz Operation Info Field. So
> is it fine if the field is carrying some info which we don't know (or
> may be don't support it yet)? Why are we masking it with _LPI_ mode?
>
> Also, I see that currently mac80211 only sets LPI or SP. So let's say
> STA is trying to connect to VLP AP, mac80211 will set it as _UNSET_.
> And then here, we will be treating it as LPI AP. Is that fine?
Currently only SP/LPI are defined in "Table E-12—Regulatory Info
subfield encoding in the United States" of IEEE Std 802.11ax™‐2021.
So maybe I need to set power_type to VLP when it is UNSET here.
>
>
>
On 9/20/23 13:53, Wen Gong wrote:
> There are two power types for 6 GHz regulatory, one is AP, another
> is client.
>
> When wlan boot up, WMI_REG_CHAN_LIST_CC_EXT_EVENTID is sent from
> firmware at an early stage, the interface mode is not decided at
> this point, then ath11k select reg rules of AP type as default.
>
> After interface is created, it is exactly decided the interface
> type such as AP/mesh point/station. Then ath11k need to update
> reg rules to the exact power type matched to the interface type.
>
> The client power type is used for station interface, and AP power
> type is used for AP/mesh point interface.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> ---
> drivers/net/wireless/ath/ath11k/mac.c | 14 ++++++++++++++
> drivers/net/wireless/ath/ath11k/mac.h | 2 +-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index c071bf5841af..0512c8b0661c 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -6714,6 +6714,12 @@ static int ath11k_mac_vdev_delete(struct ath11k *ar, struct ath11k_vif *arvif)
> return ret;
> }
>
> +bool ath11k_mac_supports_6ghz_cc_ext(struct ath11k *ar)
> +{
> + return (test_bit(WMI_TLV_SERVICE_REG_CC_EXT_EVENT_SUPPORT,
> + ar->ab->wmi_ab.svc_map)) && ar->supports_6ghz;
> +}
> +
Primarily we are checking whether WMI service is advertised or not, so
better place to keep this function would be in wmi.c?
On 9/20/2023 1:23 AM, Wen Gong wrote:
> When station connect to AP on 6 GHz band, it needs switch the regulatory
> rules according to the regulatory info sub field in HE operation element.
> Switch to the power type which AP used for station interface.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
On 9/20/23 13:53, Wen Gong wrote:
> When station is connected to a 6 GHz AP, it has 2 way to configure
> the power limit to firmware. The first way is to send 2 wmi command
> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
> firmware which include more parameters for power control.
>
> When firmware support SERVICE_EXT_TPC_REG, it means firmware support
> the second way for WMI_VDEV_SET_TPC_POWER_CMDID, then ath11k discard
> BSS_CHANGED_TXPOWER flag from mac80211 which is used to the first way
> for 6 GHz band in this patch and select the second way in the subsequent
> patch.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> ---
> drivers/net/wireless/ath/ath11k/mac.c | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index f05d66913abd..a8ae281d2635 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -3396,6 +3396,18 @@ static int ath11k_mac_config_obss_pd(struct ath11k *ar,
> return 0;
> }
>
> +static bool ath11k_mac_supports_station_tpc(struct ath11k *ar,
> + struct ath11k_vif *arvif,
> + const struct cfg80211_chan_def *chandef)
> +{
> + return ath11k_mac_supports_6ghz_cc_ext(ar) &&
> + test_bit(WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT, ar->ab->wmi_ab.svc_map) &&
> + arvif->vdev_type == WMI_VDEV_TYPE_STA &&
> + arvif->vdev_subtype == WMI_VDEV_SUBTYPE_NONE &&
> + chandef->chan &&
> + chandef->chan->band == NL80211_BAND_6GHZ;
> +}
> +
> static void ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> struct ieee80211_bss_conf *info,
> @@ -3595,9 +3607,13 @@ static void ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
> if (changed & BSS_CHANGED_TXPOWER) {
> ath11k_dbg(ar->ab, ATH11K_DBG_MAC, "vdev_id %i txpower %d\n",
> arvif->vdev_id, info->txpower);
> -
> - arvif->txpower = info->txpower;
> - ath11k_mac_txpower_recalc(ar);
> + if (ath11k_mac_supports_station_tpc(ar, arvif, &info->chandef)) {
So even if user wants to operate in low power value, we won't be
allowing to do that in case of 6 GHz station mode? Only TPC power is valid?
> + ath11k_dbg(ar->ab, ATH11K_DBG_MAC,
> + "discard tx power, change to set TPC power\n");
> + } else {
> + arvif->txpower = info->txpower;
> + ath11k_mac_txpower_recalc(ar);
> + }
> }
>
> if (changed & BSS_CHANGED_PS &&
On 9/22/23 15:42, Wen Gong wrote:
> On 9/22/2023 5:24 PM, Aditya Kumar Singh wrote:
>> On 9/20/23 13:53, Wen Gong wrote:
>>> When station is connected to a 6 GHz AP, it has 2 way to configure
>>> the power limit to firmware. The first way is to send 2 wmi command
>>> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
>>> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
>>> firmware which include more parameters for power control.
>>>
>>> The first way is disabled in previous patch
>>> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6
>>> GHz".
>>>
>>> Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
>>> send the firmware after vdev start response success from firmware, it
>>> is for the second way of power control.
>>>
>>> Tested-on: WCN6855 hw2.0 PCI
>>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>>>
>>> Signed-off-by: Wen Gong <[email protected]>
>>> ---
>>> drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
>>> b/drivers/net/wireless/ath/ath11k/mac.c
>>> index a8ae281d2635..f8b907a758b1 100644
>>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>>> @@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct
>>> ath11k_vif *arvif,
>>> return ret;
>>> }
>>> + if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
>>> + ath11k_mac_fill_reg_tpc_info(ar, arvif->vif, &arvif->chanctx);
>> So we are passing local copy of channel context stored in
>> arvif->chanctx. Do we need to update it when channel changes?
>>
>> I see that during assignment time, we are copying/updating it and
>> accordingly the command will be sent to firmware, but what about when
>> STA moves channel? arvif->chanctx should be updated and tpc command
>> should be sent again in that case?
>
> This has been discussed before here per question of Johannes:"Could this
> information change? Should we track it in beacons?":
>
> [PATCH 9/9] mac80211: save transmit power envelope element and power
> constraint
>
> https://lore.kernel.org/linux-wireless/[email protected]/
That's fine. That's w.r.t to TX power change. I'm saying here about CSA?
What when AP tries to switch channel? For that client need not
disassociate and associate back right?
In that case, channel context in mac80211 layer will change. But our
driver's arvif->chanctx will have previous one only. We are using
channel context to get the ieee80211_channel which has the PSD value,
and that value we are sending to firmware via TPC command during intial
association time. So when channel changes, firmware also should be
updated with the latest PSD values via TPC command for the latest
channel right?
On 9/22/23 15:32, Wen Gong wrote:
> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote:
>> On 9/20/23 13:53, Wen Gong wrote:
>>
>>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
>>> + ctx->def.chan->band == NL80211_BAND_6GHZ &&
>>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) {
>>> + reg_info = &ab->reg_info_store[ar->pdev_idx];
>>> + power_type = vif->bss_conf.power_type;
>>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n",
>>> + power_type);
>>> + if (power_type == IEEE80211_REG_UNSET_AP)
>>> + power_type = IEEE80211_REG_LPI_AP;
>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine?
>> Typically, during association, we would be setting this from the
>> beacon/association response frame's HE 6 GHz Operation Info Field. So
>> is it fine if the field is carrying some info which we don't know (or
>> may be don't support it yet)? Why are we masking it with _LPI_ mode?
>>
>> Also, I see that currently mac80211 only sets LPI or SP. So let's say
>> STA is trying to connect to VLP AP, mac80211 will set it as _UNSET_.
>> And then here, we will be treating it as LPI AP. Is that fine?
>
> Currently only SP/LPI are defined in "Table E-12—Regulatory Info
> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021.
>
> So maybe I need to set power_type to VLP when it is UNSET here.
Yeah, or may be deny association if we don't support that mode? I would
let others comment on this.
On 9/20/23 13:53, Wen Gong wrote:
> When station is connected to a 6 GHz AP, it has 2 way to configure
> the power limit to firmware. The first way is to send 2 wmi command
> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
> firmware which include more parameters for power control.
>
> The first way is disabled in previous patch
> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6 GHz".
>
> Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
> send the firmware after vdev start response success from firmware, it
> is for the second way of power control.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> ---
> drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index a8ae281d2635..f8b907a758b1 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct ath11k_vif *arvif,
> return ret;
> }
>
> + if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
> + ath11k_mac_fill_reg_tpc_info(ar, arvif->vif, &arvif->chanctx);
So we are passing local copy of channel context stored in
arvif->chanctx. Do we need to update it when channel changes?
I see that during assignment time, we are copying/updating it and
accordingly the command will be sent to firmware, but what about when
STA moves channel? arvif->chanctx should be updated and tpc command
should be sent again in that case?
> + ath11k_wmi_send_vdev_set_tpc_power(ar, arvif->vdev_id,
> + &arvif->reg_tpc_info);
> + }
> +
> if (!restart)
> ar->num_started_vdevs++;
>
> @@ -8108,7 +8114,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
> if (power_type == IEEE80211_REG_UNSET_AP)
> power_type = IEEE80211_REG_LPI_AP;
> ath11k_reg_handle_chan_list(ab, reg_info, power_type);
> -
> + arvif->chanctx = *ctx;
> ath11k_mac_parse_tx_pwr_env(ar, vif, ctx);
> }
>
On 9/20/2023 1:23 AM, Wen Gong wrote:
> When station is connected to a 6 GHz AP, it has 2 way to configure
s/way/ways/
> the power limit to firmware. The first way is to send 2 wmi command
s/wmi command/WMI commands/
> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
> firmware which include more parameters for power control.
Why would LIMIT2G/LIMIT5G be used for 6 GHz AP?
>
> When firmware support SERVICE_EXT_TPC_REG, it means firmware support
> the second way for WMI_VDEV_SET_TPC_POWER_CMDID, then ath11k discard
> BSS_CHANGED_TXPOWER flag from mac80211 which is used to the first way
> for 6 GHz band in this patch and select the second way in the subsequent
> patch.
So if i bisect at this patch and if firmware supports
SERVICE_EXT_TPC_REG, then there will not be any power limits sent to
firmware?
Ideally all patches in a series should be able to be bisected without
introducing regressive behavior.
Does it make sense to squash patches 11 and 13 so that there is no
regression? Patch 12 would then come before the squashed patch.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> ---
> drivers/net/wireless/ath/ath11k/mac.c | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index f05d66913abd..a8ae281d2635 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -3396,6 +3396,18 @@ static int ath11k_mac_config_obss_pd(struct ath11k *ar,
> return 0;
> }
>
> +static bool ath11k_mac_supports_station_tpc(struct ath11k *ar,
> + struct ath11k_vif *arvif,
> + const struct cfg80211_chan_def *chandef)
> +{
> + return ath11k_mac_supports_6ghz_cc_ext(ar) &&
> + test_bit(WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT, ar->ab->wmi_ab.svc_map) &&
> + arvif->vdev_type == WMI_VDEV_TYPE_STA &&
> + arvif->vdev_subtype == WMI_VDEV_SUBTYPE_NONE &&
> + chandef->chan &&
> + chandef->chan->band == NL80211_BAND_6GHZ;
> +}
> +
> static void ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> struct ieee80211_bss_conf *info,
> @@ -3595,9 +3607,13 @@ static void ath11k_mac_op_bss_info_changed(struct ieee80211_hw *hw,
> if (changed & BSS_CHANGED_TXPOWER) {
> ath11k_dbg(ar->ab, ATH11K_DBG_MAC, "vdev_id %i txpower %d\n",
> arvif->vdev_id, info->txpower);
> -
> - arvif->txpower = info->txpower;
> - ath11k_mac_txpower_recalc(ar);
> + if (ath11k_mac_supports_station_tpc(ar, arvif, &info->chandef)) {
> + ath11k_dbg(ar->ab, ATH11K_DBG_MAC,
> + "discard tx power, change to set TPC power\n");
> + } else {
> + arvif->txpower = info->txpower;
> + ath11k_mac_txpower_recalc(ar);
> + }
> }
>
> if (changed & BSS_CHANGED_PS &&
On 9/20/2023 1:23 AM, Wen Gong wrote:
> Prepare the parameters which is needed for WMI command WMI_VDEV_SET_TPC_POWER_CMDID.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> ---
> drivers/net/wireless/ath/ath11k/mac.c | 277 ++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath11k/mac.h | 3 +
> 2 files changed, 280 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index bfb900d98347..f05d66913abd 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -7661,6 +7661,283 @@ static u8 ath11k_mac_get_num_pwr_levels(struct cfg80211_chan_def *chan_def)
> }
> }
>
> +static u16 ath11k_mac_get_6ghz_start_frequency(struct cfg80211_chan_def *chan_def)
> +{
> + u16 diff_seq;
> +
> + /* It is to get the lowest channel number's center frequency of the chan.
> + * For example,
> + * bandwidth=40 MHz, center frequency is 5965, lowest channel is 1
> + * with center frequency 5955, its diff is 5965 - 5955 = 10.
> + * bandwidth=80 MHz, center frequency is 5985, lowest channel is 1
> + * with center frequency 5955, its diff is 5985 - 5955 = 30.
> + * bandwidth=160 MHz, center frequency is 6025, lowest channel is 1
> + * with center frequency 5955, its diff is 6025 - 5955 = 70.
> + */
> + switch (chan_def->width) {
> + case NL80211_CHAN_WIDTH_160:
> + diff_seq = 70;
> + break;
> + case NL80211_CHAN_WIDTH_80:
> + case NL80211_CHAN_WIDTH_80P80:
> + diff_seq = 30;
> + break;
> + case NL80211_CHAN_WIDTH_40:
> + diff_seq = 10;
> + break;
> + default:
> + diff_seq = 0;
> + }
> +
> + return chan_def->center_freq1 - diff_seq;
> +}
> +
> +static u16 ath11k_mac_get_seg_freq(struct cfg80211_chan_def *chan_def,
> + u16 start_seq, u8 seq)
> +{
> + u16 seg_seq;
> +
> + /* It is to get the center frequency of the specific bandwidth.
> + * start_seq means the lowest channel number's center frequency.
> + * seq 0/1/2/3 means 20 MHz/40 MHz/80 MHz/160 MHz&80P80.
> + * For example,
> + * lowest channel is 1, its center frequency 5955,
> + * center frequency is 5955 when bandwidth=20 MHz, its diff is 5955 - 5955 = 0.
> + * lowest channel is 1, its center frequency 5955,
> + * center frequency is 5965 when bandwidth=40 MHz, its diff is 5965 - 5955 = 10.
> + * lowest channel is 1, its center frequency 5955,
> + * center frequency is 5985 when bandwidth=80 MHz, its diff is 5985 - 5955 = 30.
> + * lowest channel is 1, its center frequency 5955,
> + * center frequency is 6025 when bandwidth=160 MHz, its diff is 6025 - 5955 = 70.
> + */
> + if (chan_def->width == NL80211_CHAN_WIDTH_80P80 && seq == 3)
> + return chan_def->center_freq2;
> +
> + seg_seq = 10 * (BIT(seq) - 1);
> + return seg_seq + start_seq;
> +}
The above two functions are driver agnostic. Will other drivers need
this as well, and if so, should these go into core wireless?
On 9/25/23 07:45, Wen Gong wrote:
> On 9/22/2023 9:25 PM, Aditya Kumar Singh wrote:
>> On 9/22/23 15:42, Wen Gong wrote:
>>> On 9/22/2023 5:24 PM, Aditya Kumar Singh wrote:
>>>> On 9/20/23 13:53, Wen Gong wrote:
>>>>> When station is connected to a 6 GHz AP, it has 2 way to configure
>>>>> the power limit to firmware. The first way is to send 2 wmi command
>>>>> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
>>>>> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
>>>>> firmware which include more parameters for power control.
>>>>>
>>>>> The first way is disabled in previous patch
>>>>> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6
>>>>> GHz".
>>>>>
>>>>> Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
>>>>> send the firmware after vdev start response success from firmware, it
>>>>> is for the second way of power control.
>>>>>
>>>>> Tested-on: WCN6855 hw2.0 PCI
>>>>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>>>>>
>>>>> Signed-off-by: Wen Gong <[email protected]>
>>>>> ---
>>>>> drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
>>>>> b/drivers/net/wireless/ath/ath11k/mac.c
>>>>> index a8ae281d2635..f8b907a758b1 100644
>>>>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>>>>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>>>>> @@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct
>>>>> ath11k_vif *arvif,
>>>>> return ret;
>>>>> }
>>>>> + if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
>>>>> + ath11k_mac_fill_reg_tpc_info(ar, arvif->vif,
>>>>> &arvif->chanctx);
>>>> So we are passing local copy of channel context stored in
>>>> arvif->chanctx. Do we need to update it when channel changes?
>>>>
>>>> I see that during assignment time, we are copying/updating it and
>>>> accordingly the command will be sent to firmware, but what about
>>>> when STA moves channel? arvif->chanctx should be updated and tpc
>>>> command should be sent again in that case?
>>>
>>> This has been discussed before here per question of Johannes:"Could
>>> this information change? Should we track it in beacons?":
>>>
>>> [PATCH 9/9] mac80211: save transmit power envelope element and power
>>> constraint
>>>
>>> https://lore.kernel.org/linux-wireless/[email protected]/
>> That's fine. That's w.r.t to TX power change. I'm saying here about
>> CSA? What when AP tries to switch channel? For that client need not
>> disassociate and associate back right?
>>
>> In that case, channel context in mac80211 layer will change. But our
>> driver's arvif->chanctx will have previous one only. We are using
>> channel context to get the ieee80211_channel which has the PSD value,
>> and that value we are sending to firmware via TPC command during
>> intial association time. So when channel changes, firmware also should
>> be updated with the latest PSD values via TPC command for the latest
>> channel right?
>>
> You are right. CSA may be change channel bandwidth.
>
> Currently we could keep NOT support CSA as well as CSA for MLO since
> these are the basic TPC support feature.
>
> We could make new patch later to support CSA fro TPC power, OK?
Not supporting w.r.t MLO CSA is okay. That's WIP. But for non-MLO case,
I think it should be supported. And if not, then may be explicitly
mention it somewhere as _TODO_ ? What if by the time patch is sent for
that, meanwhile a bug is filed?
Anyways, I will let maintainers take a call on this. I don't have any
further comments.
On 9/22/2023 9:25 PM, Aditya Kumar Singh wrote:
> On 9/22/23 15:42, Wen Gong wrote:
>> On 9/22/2023 5:24 PM, Aditya Kumar Singh wrote:
>>> On 9/20/23 13:53, Wen Gong wrote:
>>>> When station is connected to a 6 GHz AP, it has 2 way to configure
>>>> the power limit to firmware. The first way is to send 2 wmi command
>>>> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
>>>> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
>>>> firmware which include more parameters for power control.
>>>>
>>>> The first way is disabled in previous patch
>>>> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for 6
>>>> GHz".
>>>>
>>>> Prepare the parameter for wmi command WMI_VDEV_SET_TPC_POWER_CMDID and
>>>> send the firmware after vdev start response success from firmware, it
>>>> is for the second way of power control.
>>>>
>>>> Tested-on: WCN6855 hw2.0 PCI
>>>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>>>>
>>>> Signed-off-by: Wen Gong <[email protected]>
>>>> ---
>>>> drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
>>>> b/drivers/net/wireless/ath/ath11k/mac.c
>>>> index a8ae281d2635..f8b907a758b1 100644
>>>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>>>> @@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct
>>>> ath11k_vif *arvif,
>>>> return ret;
>>>> }
>>>> + if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
>>>> + ath11k_mac_fill_reg_tpc_info(ar, arvif->vif,
>>>> &arvif->chanctx);
>>> So we are passing local copy of channel context stored in
>>> arvif->chanctx. Do we need to update it when channel changes?
>>>
>>> I see that during assignment time, we are copying/updating it and
>>> accordingly the command will be sent to firmware, but what about
>>> when STA moves channel? arvif->chanctx should be updated and tpc
>>> command should be sent again in that case?
>>
>> This has been discussed before here per question of Johannes:"Could
>> this information change? Should we track it in beacons?":
>>
>> [PATCH 9/9] mac80211: save transmit power envelope element and power
>> constraint
>>
>> https://lore.kernel.org/linux-wireless/[email protected]/
>>
> That's fine. That's w.r.t to TX power change. I'm saying here about
> CSA? What when AP tries to switch channel? For that client need not
> disassociate and associate back right?
>
> In that case, channel context in mac80211 layer will change. But our
> driver's arvif->chanctx will have previous one only. We are using
> channel context to get the ieee80211_channel which has the PSD value,
> and that value we are sending to firmware via TPC command during
> intial association time. So when channel changes, firmware also should
> be updated with the latest PSD values via TPC command for the latest
> channel right?
>
You are right. CSA may be change channel bandwidth.
Currently we could keep NOT support CSA as well as CSA for MLO since
these are the basic TPC support feature.
We could make new patch later to support CSA fro TPC power, OK?
>
>
On 9/25/2023 6:52 PM, Aditya Kumar Singh wrote:
> On 9/25/23 16:13, Wen Gong wrote:
>> On 9/22/2023 9:18 PM, Aditya Kumar Singh wrote:
>>> On 9/22/23 15:32, Wen Gong wrote:
>>>> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote:
>>>>> On 9/20/23 13:53, Wen Gong wrote:
>>>>>
>>>>>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
>>>>>> + ctx->def.chan->band == NL80211_BAND_6GHZ &&
>>>>>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) {
>>>>>> + reg_info = &ab->reg_info_store[ar->pdev_idx];
>>>>>> + power_type = vif->bss_conf.power_type;
>>>>>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type
>>>>>> %d\n",
>>>>>> + power_type);
>>>>>> + if (power_type == IEEE80211_REG_UNSET_AP)
>>>>>> + power_type = IEEE80211_REG_LPI_AP;
>>>>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine?
>>>>> Typically, during association, we would be setting this from the
>>>>> beacon/association response frame's HE 6 GHz Operation Info Field.
>>>>> So is it fine if the field is carrying some info which we don't
>>>>> know (or may be don't support it yet)? Why are we masking it with
>>>>> _LPI_ mode?
>>>>>
>>>>> Also, I see that currently mac80211 only sets LPI or SP. So let's
>>>>> say STA is trying to connect to VLP AP, mac80211 will set it as
>>>>> _UNSET_. And then here, we will be treating it as LPI AP. Is that
>>>>> fine?
>>>>
>>>> Currently only SP/LPI are defined in "Table E-12—Regulatory Info
>>>> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021.
>>>>
>>>> So maybe I need to set power_type to VLP when it is UNSET here.
>>> Yeah, or may be deny association if we don't support that mode? I
>>> would let others comment on this.
>> Do you know how to check which mode support by ath11k?
> IMHO we should not maintain two different supported modes, one in
> driver and another in mac80211. I mean w.r.t mac80211 we should try to
> match it as far as possible. In this case, we can return error from
> mac80211 itself when a non-supported mode (as in VLP) is trying to
> associate? Since as you have quoted, VLP is not yet defined in spec
> IEEE Std 802.11ax‐2021 so why to mask the mode and continue in
> mac80211 itself?
>
> If we do like this, then mac80211 will not simply set _UNSET_ for 6
> GHz client interface and in driver if we see its still _UNSET_ then we
> can be sure that something has gone wrong and we can take steps
> accordingly.
Yes, I will change to return fail for _UNSET_.
On 9/25/23 16:13, Wen Gong wrote:
> On 9/22/2023 9:18 PM, Aditya Kumar Singh wrote:
>> On 9/22/23 15:32, Wen Gong wrote:
>>> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote:
>>>> On 9/20/23 13:53, Wen Gong wrote:
>>>>
>>>>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
>>>>> + ctx->def.chan->band == NL80211_BAND_6GHZ &&
>>>>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) {
>>>>> + reg_info = &ab->reg_info_store[ar->pdev_idx];
>>>>> + power_type = vif->bss_conf.power_type;
>>>>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n",
>>>>> + power_type);
>>>>> + if (power_type == IEEE80211_REG_UNSET_AP)
>>>>> + power_type = IEEE80211_REG_LPI_AP;
>>>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine?
>>>> Typically, during association, we would be setting this from the
>>>> beacon/association response frame's HE 6 GHz Operation Info Field.
>>>> So is it fine if the field is carrying some info which we don't know
>>>> (or may be don't support it yet)? Why are we masking it with _LPI_
>>>> mode?
>>>>
>>>> Also, I see that currently mac80211 only sets LPI or SP. So let's
>>>> say STA is trying to connect to VLP AP, mac80211 will set it as
>>>> _UNSET_. And then here, we will be treating it as LPI AP. Is that fine?
>>>
>>> Currently only SP/LPI are defined in "Table E-12—Regulatory Info
>>> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021.
>>>
>>> So maybe I need to set power_type to VLP when it is UNSET here.
>> Yeah, or may be deny association if we don't support that mode? I
>> would let others comment on this.
> Do you know how to check which mode support by ath11k?
IMHO we should not maintain two different supported modes, one in driver
and another in mac80211. I mean w.r.t mac80211 we should try to match it
as far as possible. In this case, we can return error from mac80211
itself when a non-supported mode (as in VLP) is trying to associate?
Since as you have quoted, VLP is not yet defined in spec IEEE Std
802.11ax‐2021 so why to mask the mode and continue in mac80211 itself?
If we do like this, then mac80211 will not simply set _UNSET_ for 6 GHz
client interface and in driver if we see its still _UNSET_ then we can
be sure that something has gone wrong and we can take steps accordingly.
On 9/22/2023 4:11 AM, Jeff Johnson wrote:
> On 9/20/2023 1:23 AM, Wen Gong wrote:
>> Prepare the parameters which is needed for WMI command
>> WMI_VDEV_SET_TPC_POWER_CMDID.
>>
>> Tested-on: WCN6855 hw2.0 PCI
>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>>
>> Signed-off-by: Wen Gong <[email protected]>
>> ---
>> drivers/net/wireless/ath/ath11k/mac.c | 277 ++++++++++++++++++++++++++
>> drivers/net/wireless/ath/ath11k/mac.h | 3 +
>> 2 files changed, 280 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
>> b/drivers/net/wireless/ath/ath11k/mac.c
>> index bfb900d98347..f05d66913abd 100644
>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>> @@ -7661,6 +7661,283 @@ static u8
>> ath11k_mac_get_num_pwr_levels(struct cfg80211_chan_def *chan_def)
>> }
>> }
>> +static u16 ath11k_mac_get_6ghz_start_frequency(struct
>> cfg80211_chan_def *chan_def)
>> +{
>> + u16 diff_seq;
>> +
>> + /* It is to get the lowest channel number's center frequency of
>> the chan.
>> + * For example,
>> + * bandwidth=40 MHz, center frequency is 5965, lowest channel is 1
>> + * with center frequency 5955, its diff is 5965 - 5955 = 10.
>> + * bandwidth=80 MHz, center frequency is 5985, lowest channel is 1
>> + * with center frequency 5955, its diff is 5985 - 5955 = 30.
>> + * bandwidth=160 MHz, center frequency is 6025, lowest channel is 1
>> + * with center frequency 5955, its diff is 6025 - 5955 = 70.
>> + */
>> + switch (chan_def->width) {
>> + case NL80211_CHAN_WIDTH_160:
>> + diff_seq = 70;
>> + break;
>> + case NL80211_CHAN_WIDTH_80:
>> + case NL80211_CHAN_WIDTH_80P80:
>> + diff_seq = 30;
>> + break;
>> + case NL80211_CHAN_WIDTH_40:
>> + diff_seq = 10;
>> + break;
>> + default:
>> + diff_seq = 0;
>> + }
>> +
>> + return chan_def->center_freq1 - diff_seq;
>> +}
>> +
>> +static u16 ath11k_mac_get_seg_freq(struct cfg80211_chan_def *chan_def,
>> + u16 start_seq, u8 seq)
>> +{
>> + u16 seg_seq;
>> +
>> + /* It is to get the center frequency of the specific bandwidth.
>> + * start_seq means the lowest channel number's center frequency.
>> + * seq 0/1/2/3 means 20 MHz/40 MHz/80 MHz/160 MHz&80P80.
>> + * For example,
>> + * lowest channel is 1, its center frequency 5955,
>> + * center frequency is 5955 when bandwidth=20 MHz, its diff is
>> 5955 - 5955 = 0.
>> + * lowest channel is 1, its center frequency 5955,
>> + * center frequency is 5965 when bandwidth=40 MHz, its diff is
>> 5965 - 5955 = 10.
>> + * lowest channel is 1, its center frequency 5955,
>> + * center frequency is 5985 when bandwidth=80 MHz, its diff is
>> 5985 - 5955 = 30.
>> + * lowest channel is 1, its center frequency 5955,
>> + * center frequency is 6025 when bandwidth=160 MHz, its diff is
>> 6025 - 5955 = 70.
>> + */
>> + if (chan_def->width == NL80211_CHAN_WIDTH_80P80 && seq == 3)
>> + return chan_def->center_freq2;
>> +
>> + seg_seq = 10 * (BIT(seq) - 1);
>> + return seg_seq + start_seq;
>> +}
>
> The above two functions are driver agnostic. Will other drivers need
> this as well, and if so, should these go into core wireless?
>
Not found other driver need it. If move them to core wireless, then it
will be a new dependency for it.
On 9/25/2023 1:41 PM, Aditya Kumar Singh wrote:
> On 9/25/23 07:45, Wen Gong wrote:
>> On 9/22/2023 9:25 PM, Aditya Kumar Singh wrote:
>>> On 9/22/23 15:42, Wen Gong wrote:
>>>> On 9/22/2023 5:24 PM, Aditya Kumar Singh wrote:
>>>>> On 9/20/23 13:53, Wen Gong wrote:
>>>>>> When station is connected to a 6 GHz AP, it has 2 way to configure
>>>>>> the power limit to firmware. The first way is to send 2 wmi command
>>>>>> WMI_PDEV_PARAM_TXPOWER_LIMIT2G/WMI_PDEV_PARAM_TXPOWER_LIMIT5G to
>>>>>> firmware, the second way is to send WMI_VDEV_SET_TPC_POWER_CMDID to
>>>>>> firmware which include more parameters for power control.
>>>>>>
>>>>>> The first way is disabled in previous patch
>>>>>> "ath11k: discard BSS_CHANGED_TXPOWER when EXT_TPC_REG_SUPPORT for
>>>>>> 6 GHz".
>>>>>>
>>>>>> Prepare the parameter for wmi command
>>>>>> WMI_VDEV_SET_TPC_POWER_CMDID and
>>>>>> send the firmware after vdev start response success from
>>>>>> firmware, it
>>>>>> is for the second way of power control.
>>>>>>
>>>>>> Tested-on: WCN6855 hw2.0 PCI
>>>>>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>>>>>>
>>>>>> Signed-off-by: Wen Gong <[email protected]>
>>>>>> ---
>>>>>> drivers/net/wireless/ath/ath11k/mac.c | 8 +++++++-
>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c
>>>>>> b/drivers/net/wireless/ath/ath11k/mac.c
>>>>>> index a8ae281d2635..f8b907a758b1 100644
>>>>>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>>>>>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>>>>>> @@ -7296,6 +7296,12 @@ ath11k_mac_vdev_start_restart(struct
>>>>>> ath11k_vif *arvif,
>>>>>> return ret;
>>>>>> }
>>>>>> + if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
>>>>>> + ath11k_mac_fill_reg_tpc_info(ar, arvif->vif,
>>>>>> &arvif->chanctx);
>>>>> So we are passing local copy of channel context stored in
>>>>> arvif->chanctx. Do we need to update it when channel changes?
>>>>>
>>>>> I see that during assignment time, we are copying/updating it and
>>>>> accordingly the command will be sent to firmware, but what about
>>>>> when STA moves channel? arvif->chanctx should be updated and tpc
>>>>> command should be sent again in that case?
>>>>
>>>> This has been discussed before here per question of Johannes:"Could
>>>> this information change? Should we track it in beacons?":
>>>>
>>>> [PATCH 9/9] mac80211: save transmit power envelope element and
>>>> power constraint
>>>>
>>>> https://lore.kernel.org/linux-wireless/[email protected]/
>>>>
>>> That's fine. That's w.r.t to TX power change. I'm saying here about
>>> CSA? What when AP tries to switch channel? For that client need not
>>> disassociate and associate back right?
>>>
>>> In that case, channel context in mac80211 layer will change. But our
>>> driver's arvif->chanctx will have previous one only. We are using
>>> channel context to get the ieee80211_channel which has the PSD
>>> value, and that value we are sending to firmware via TPC command
>>> during intial association time. So when channel changes, firmware
>>> also should be updated with the latest PSD values via TPC command
>>> for the latest channel right?
>>>
>> You are right. CSA may be change channel bandwidth.
>>
>> Currently we could keep NOT support CSA as well as CSA for MLO since
>> these are the basic TPC support feature.
>>
>> We could make new patch later to support CSA fro TPC power, OK?
> Not supporting w.r.t MLO CSA is okay. That's WIP. But for non-MLO
> case, I think it should be supported. And if not, then may be
> explicitly mention it somewhere as _TODO_ ? What if by the time patch
> is sent for that, meanwhile a bug is filed?
I will add _TODO_ next version as you said.
>
> Anyways, I will let maintainers take a call on this. I don't have any
> further comments.
>
On 9/22/2023 9:18 PM, Aditya Kumar Singh wrote:
> On 9/22/23 15:32, Wen Gong wrote:
>> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote:
>>> On 9/20/23 13:53, Wen Gong wrote:
>>>
>>>> + if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
>>>> + ctx->def.chan->band == NL80211_BAND_6GHZ &&
>>>> + arvif->vdev_type == WMI_VDEV_TYPE_STA) {
>>>> + reg_info = &ab->reg_info_store[ar->pdev_idx];
>>>> + power_type = vif->bss_conf.power_type;
>>>> + ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type %d\n",
>>>> + power_type);
>>>> + if (power_type == IEEE80211_REG_UNSET_AP)
>>>> + power_type = IEEE80211_REG_LPI_AP;
>>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine?
>>> Typically, during association, we would be setting this from the
>>> beacon/association response frame's HE 6 GHz Operation Info Field.
>>> So is it fine if the field is carrying some info which we don't know
>>> (or may be don't support it yet)? Why are we masking it with _LPI_
>>> mode?
>>>
>>> Also, I see that currently mac80211 only sets LPI or SP. So let's
>>> say STA is trying to connect to VLP AP, mac80211 will set it as
>>> _UNSET_. And then here, we will be treating it as LPI AP. Is that fine?
>>
>> Currently only SP/LPI are defined in "Table E-12—Regulatory Info
>> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021.
>>
>> So maybe I need to set power_type to VLP when it is UNSET here.
> Yeah, or may be deny association if we don't support that mode? I
> would let others comment on this.
Do you know how to check which mode support by ath11k?
Wen Gong <[email protected]> wrote:
> The regulatory info of WMI_REG_CHAN_LIST_CC_EXT_EVENTID is not saved
> in ath11k now, the info should be saved in ath11k. Save the info for
> each radio and support switch regulatory rules dynamically.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> Acked-by: Jeff Johnson <[email protected]>
> Signed-off-by: Kalle Valo <[email protected]>
This added a new warning:
drivers/net/wireless/ath/ath11k/wmi.c:7157: else is not generally useful after a break or return
You should guess by now what I'm going to say: please ALWAYS test your patches
with ath11k-check!
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Wen Gong <[email protected]> wrote:
> Prepare the parameters which is needed for WMI command WMI_VDEV_SET_TPC_POWER_CMDID.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <[email protected]>
> Acked-by: Jeff Johnson <[email protected]>
> Signed-off-by: Kalle Valo <[email protected]>
And this also added new warnings:
drivers/net/wireless/ath/ath11k/mac.c: In function 'ath11k_mac_fill_reg_tpc_info':
drivers/net/wireless/ath/ath11k/mac.c:7791:13: error: variable 'oper_freq' set but not used [-Werror=unused-but-set-variable]
drivers/net/wireless/ath/ath11k/mac.c:7731: Possible repeated word: 'the'
drivers/net/wireless/ath/ath11k/mac.c:7755: Possible repeated word: 'the'
I fixed them in the pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=c9f905ac838d9a7d79adb49951c7b0579d020c0a
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches