2019-06-04 08:11:33 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-10-10 11:33:04 +00:00
|
|
|
/*
|
|
|
|
* VHT handling
|
|
|
|
*
|
2015-12-08 14:04:31 +00:00
|
|
|
* Portions of this file
|
2016-02-16 10:48:17 +00:00
|
|
|
* Copyright(c) 2015 - 2016 Intel Deutschland GmbH
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 11:26:44 +00:00
|
|
|
* Copyright (C) 2018 - 2022 Intel Corporation
|
2012-10-10 11:33:04 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/ieee80211.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <net/mac80211.h>
|
|
|
|
#include "ieee80211_i.h"
|
2012-12-27 17:55:36 +00:00
|
|
|
#include "rate.h"
|
2012-10-10 11:33:04 +00:00
|
|
|
|
|
|
|
|
2013-02-21 16:40:19 +00:00
|
|
|
static void __check_vhtcap_disable(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct ieee80211_sta_vht_cap *vht_cap,
|
|
|
|
u32 flag)
|
|
|
|
{
|
|
|
|
__le32 le_flag = cpu_to_le32(flag);
|
|
|
|
|
|
|
|
if (sdata->u.mgd.vht_capa_mask.vht_cap_info & le_flag &&
|
|
|
|
!(sdata->u.mgd.vht_capa.vht_cap_info & le_flag))
|
|
|
|
vht_cap->cap &= ~flag;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_apply_vhtcap_overrides(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct ieee80211_sta_vht_cap *vht_cap)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u16 rxmcs_mask, rxmcs_cap, rxmcs_n, txmcs_mask, txmcs_cap, txmcs_n;
|
|
|
|
|
|
|
|
if (!vht_cap->vht_supported)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (sdata->vif.type != NL80211_IFTYPE_STATION)
|
|
|
|
return;
|
|
|
|
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_RXLDPC);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_SHORT_GI_80);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_SHORT_GI_160);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_TXSTBC);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_RX_ANTENNA_PATTERN);
|
|
|
|
__check_vhtcap_disable(sdata, vht_cap,
|
|
|
|
IEEE80211_VHT_CAP_TX_ANTENNA_PATTERN);
|
|
|
|
|
|
|
|
/* Allow user to decrease AMPDU length exponent */
|
|
|
|
if (sdata->u.mgd.vht_capa_mask.vht_cap_info &
|
|
|
|
cpu_to_le32(IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK)) {
|
|
|
|
u32 cap, n;
|
|
|
|
|
|
|
|
n = le32_to_cpu(sdata->u.mgd.vht_capa.vht_cap_info) &
|
|
|
|
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK;
|
|
|
|
n >>= IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_SHIFT;
|
|
|
|
cap = vht_cap->cap & IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK;
|
|
|
|
cap >>= IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_SHIFT;
|
|
|
|
|
|
|
|
if (n < cap) {
|
|
|
|
vht_cap->cap &=
|
|
|
|
~IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK;
|
|
|
|
vht_cap->cap |=
|
|
|
|
n << IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_SHIFT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allow the user to decrease MCSes */
|
|
|
|
rxmcs_mask =
|
|
|
|
le16_to_cpu(sdata->u.mgd.vht_capa_mask.supp_mcs.rx_mcs_map);
|
|
|
|
rxmcs_n = le16_to_cpu(sdata->u.mgd.vht_capa.supp_mcs.rx_mcs_map);
|
|
|
|
rxmcs_n &= rxmcs_mask;
|
|
|
|
rxmcs_cap = le16_to_cpu(vht_cap->vht_mcs.rx_mcs_map);
|
|
|
|
|
|
|
|
txmcs_mask =
|
|
|
|
le16_to_cpu(sdata->u.mgd.vht_capa_mask.supp_mcs.tx_mcs_map);
|
|
|
|
txmcs_n = le16_to_cpu(sdata->u.mgd.vht_capa.supp_mcs.tx_mcs_map);
|
|
|
|
txmcs_n &= txmcs_mask;
|
|
|
|
txmcs_cap = le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map);
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
u8 m, n, c;
|
|
|
|
|
|
|
|
m = (rxmcs_mask >> 2*i) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
n = (rxmcs_n >> 2*i) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
c = (rxmcs_cap >> 2*i) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
if (m && ((c != IEEE80211_VHT_MCS_NOT_SUPPORTED && n < c) ||
|
|
|
|
n == IEEE80211_VHT_MCS_NOT_SUPPORTED)) {
|
|
|
|
rxmcs_cap &= ~(3 << 2*i);
|
|
|
|
rxmcs_cap |= (rxmcs_n & (3 << 2*i));
|
|
|
|
}
|
|
|
|
|
|
|
|
m = (txmcs_mask >> 2*i) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
n = (txmcs_n >> 2*i) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
c = (txmcs_cap >> 2*i) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
if (m && ((c != IEEE80211_VHT_MCS_NOT_SUPPORTED && n < c) ||
|
|
|
|
n == IEEE80211_VHT_MCS_NOT_SUPPORTED)) {
|
|
|
|
txmcs_cap &= ~(3 << 2*i);
|
|
|
|
txmcs_cap |= (txmcs_n & (3 << 2*i));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
vht_cap->vht_mcs.rx_mcs_map = cpu_to_le16(rxmcs_cap);
|
|
|
|
vht_cap->vht_mcs.tx_mcs_map = cpu_to_le16(txmcs_cap);
|
|
|
|
}
|
|
|
|
|
2013-02-12 15:43:19 +00:00
|
|
|
void
|
|
|
|
ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct ieee80211_supported_band *sband,
|
|
|
|
const struct ieee80211_vht_cap *vht_cap_ie,
|
|
|
|
struct sta_info *sta)
|
2012-10-10 11:33:04 +00:00
|
|
|
{
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
struct ieee80211_sta_vht_cap *vht_cap = &sta->sta.deflink.vht_cap;
|
2013-03-01 12:07:48 +00:00
|
|
|
struct ieee80211_sta_vht_cap own_cap;
|
|
|
|
u32 cap_info, i;
|
2015-08-15 19:39:53 +00:00
|
|
|
bool have_80mhz;
|
2012-10-10 11:33:04 +00:00
|
|
|
|
|
|
|
memset(vht_cap, 0, sizeof(*vht_cap));
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (!sta->sta.deflink.ht_cap.ht_supported)
|
2013-02-07 10:58:58 +00:00
|
|
|
return;
|
|
|
|
|
2012-10-10 11:33:04 +00:00
|
|
|
if (!vht_cap_ie || !sband->vht_cap.vht_supported)
|
|
|
|
return;
|
|
|
|
|
2015-08-15 19:39:53 +00:00
|
|
|
/* Allow VHT if at least one channel on the sband supports 80 MHz */
|
|
|
|
have_80mhz = false;
|
|
|
|
for (i = 0; i < sband->n_channels; i++) {
|
|
|
|
if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
|
|
|
|
IEEE80211_CHAN_NO_80MHZ))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
have_80mhz = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!have_80mhz)
|
|
|
|
return;
|
|
|
|
|
2014-05-09 07:56:53 +00:00
|
|
|
/*
|
|
|
|
* A VHT STA must support 40 MHz, but if we verify that here
|
|
|
|
* then we break a few things - some APs (e.g. Netgear R6300v2
|
|
|
|
* and others based on the BCM4360 chipset) will unset this
|
|
|
|
* capability bit when operating in 20 MHz.
|
|
|
|
*/
|
2013-02-07 10:47:44 +00:00
|
|
|
|
2012-10-10 11:33:04 +00:00
|
|
|
vht_cap->vht_supported = true;
|
|
|
|
|
2013-03-01 12:07:48 +00:00
|
|
|
own_cap = sband->vht_cap;
|
|
|
|
/*
|
|
|
|
* If user has specified capability overrides, take care
|
|
|
|
* of that if the station we're setting up is the AP that
|
|
|
|
* we advertised a restricted capability set to. Override
|
|
|
|
* our own capabilities and then use those below.
|
|
|
|
*/
|
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
|
|
|
|
!test_sta_flag(sta, WLAN_STA_TDLS_PEER))
|
|
|
|
ieee80211_apply_vhtcap_overrides(sdata, &own_cap);
|
|
|
|
|
|
|
|
/* take some capabilities as-is */
|
|
|
|
cap_info = le32_to_cpu(vht_cap_ie->vht_cap_info);
|
|
|
|
vht_cap->cap = cap_info;
|
2020-09-17 12:50:31 +00:00
|
|
|
vht_cap->cap &= IEEE80211_VHT_CAP_RXLDPC |
|
2013-03-01 12:07:48 +00:00
|
|
|
IEEE80211_VHT_CAP_VHT_TXOP_PS |
|
|
|
|
IEEE80211_VHT_CAP_HTC_VHT |
|
|
|
|
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK |
|
|
|
|
IEEE80211_VHT_CAP_VHT_LINK_ADAPTATION_VHT_UNSOL_MFB |
|
|
|
|
IEEE80211_VHT_CAP_VHT_LINK_ADAPTATION_VHT_MRQ_MFB |
|
|
|
|
IEEE80211_VHT_CAP_RX_ANTENNA_PATTERN |
|
|
|
|
IEEE80211_VHT_CAP_TX_ANTENNA_PATTERN;
|
|
|
|
|
2020-09-17 12:50:31 +00:00
|
|
|
vht_cap->cap |= min_t(u32, cap_info & IEEE80211_VHT_CAP_MAX_MPDU_MASK,
|
|
|
|
own_cap.cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK);
|
|
|
|
|
2013-03-01 12:07:48 +00:00
|
|
|
/* and some based on our own capabilities */
|
|
|
|
switch (own_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
|
|
|
|
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
|
|
|
|
vht_cap->cap |= cap_info &
|
|
|
|
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
|
|
|
|
break;
|
|
|
|
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ:
|
|
|
|
vht_cap->cap |= cap_info &
|
|
|
|
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* nothing */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* symmetric capabilities */
|
|
|
|
vht_cap->cap |= cap_info & own_cap.cap &
|
|
|
|
(IEEE80211_VHT_CAP_SHORT_GI_80 |
|
|
|
|
IEEE80211_VHT_CAP_SHORT_GI_160);
|
|
|
|
|
|
|
|
/* remaining ones */
|
2013-11-11 18:14:00 +00:00
|
|
|
if (own_cap.cap & IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE)
|
2013-03-01 12:07:48 +00:00
|
|
|
vht_cap->cap |= cap_info &
|
|
|
|
(IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
|
2013-11-11 18:14:00 +00:00
|
|
|
IEEE80211_VHT_CAP_SOUNDING_DIMENSIONS_MASK);
|
2013-03-01 12:07:48 +00:00
|
|
|
|
|
|
|
if (own_cap.cap & IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE)
|
|
|
|
vht_cap->cap |= cap_info &
|
2013-08-29 12:03:14 +00:00
|
|
|
(IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |
|
2013-11-11 18:14:00 +00:00
|
|
|
IEEE80211_VHT_CAP_BEAMFORMEE_STS_MASK);
|
2013-03-01 12:07:48 +00:00
|
|
|
|
|
|
|
if (own_cap.cap & IEEE80211_VHT_CAP_MU_BEAMFORMER_CAPABLE)
|
|
|
|
vht_cap->cap |= cap_info &
|
|
|
|
IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE;
|
|
|
|
|
|
|
|
if (own_cap.cap & IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE)
|
|
|
|
vht_cap->cap |= cap_info &
|
|
|
|
IEEE80211_VHT_CAP_MU_BEAMFORMER_CAPABLE;
|
|
|
|
|
|
|
|
if (own_cap.cap & IEEE80211_VHT_CAP_TXSTBC)
|
|
|
|
vht_cap->cap |= cap_info & IEEE80211_VHT_CAP_RXSTBC_MASK;
|
|
|
|
|
|
|
|
if (own_cap.cap & IEEE80211_VHT_CAP_RXSTBC_MASK)
|
|
|
|
vht_cap->cap |= cap_info & IEEE80211_VHT_CAP_TXSTBC;
|
2012-10-10 11:33:04 +00:00
|
|
|
|
|
|
|
/* Copy peer MCS info, the driver might need them. */
|
|
|
|
memcpy(&vht_cap->vht_mcs, &vht_cap_ie->supp_mcs,
|
|
|
|
sizeof(struct ieee80211_vht_mcs_info));
|
2013-02-07 10:47:44 +00:00
|
|
|
|
2018-08-31 08:31:19 +00:00
|
|
|
/* copy EXT_NSS_BW Support value or remove the capability */
|
|
|
|
if (ieee80211_hw_check(&sdata->local->hw, SUPPORTS_VHT_EXT_NSS_BW))
|
|
|
|
vht_cap->cap |= (cap_info & IEEE80211_VHT_CAP_EXT_NSS_BW_MASK);
|
|
|
|
else
|
|
|
|
vht_cap->vht_mcs.tx_highest &=
|
|
|
|
~cpu_to_le16(IEEE80211_VHT_EXT_NSS_BW_CAPABLE);
|
|
|
|
|
2013-03-01 12:07:48 +00:00
|
|
|
/* but also restrict MCSes */
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
u16 own_rx, own_tx, peer_rx, peer_tx;
|
|
|
|
|
|
|
|
own_rx = le16_to_cpu(own_cap.vht_mcs.rx_mcs_map);
|
|
|
|
own_rx = (own_rx >> i * 2) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
own_tx = le16_to_cpu(own_cap.vht_mcs.tx_mcs_map);
|
|
|
|
own_tx = (own_tx >> i * 2) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
peer_rx = le16_to_cpu(vht_cap->vht_mcs.rx_mcs_map);
|
|
|
|
peer_rx = (peer_rx >> i * 2) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
peer_tx = le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map);
|
|
|
|
peer_tx = (peer_tx >> i * 2) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
if (peer_tx != IEEE80211_VHT_MCS_NOT_SUPPORTED) {
|
|
|
|
if (own_rx == IEEE80211_VHT_MCS_NOT_SUPPORTED)
|
|
|
|
peer_tx = IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
else if (own_rx < peer_tx)
|
|
|
|
peer_tx = own_rx;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (peer_rx != IEEE80211_VHT_MCS_NOT_SUPPORTED) {
|
|
|
|
if (own_tx == IEEE80211_VHT_MCS_NOT_SUPPORTED)
|
|
|
|
peer_rx = IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
else if (own_tx < peer_rx)
|
|
|
|
peer_rx = own_tx;
|
|
|
|
}
|
|
|
|
|
|
|
|
vht_cap->vht_mcs.rx_mcs_map &=
|
|
|
|
~cpu_to_le16(IEEE80211_VHT_MCS_NOT_SUPPORTED << i * 2);
|
|
|
|
vht_cap->vht_mcs.rx_mcs_map |= cpu_to_le16(peer_rx << i * 2);
|
|
|
|
|
|
|
|
vht_cap->vht_mcs.tx_mcs_map &=
|
|
|
|
~cpu_to_le16(IEEE80211_VHT_MCS_NOT_SUPPORTED << i * 2);
|
|
|
|
vht_cap->vht_mcs.tx_mcs_map |= cpu_to_le16(peer_tx << i * 2);
|
|
|
|
}
|
|
|
|
|
2016-11-02 09:04:26 +00:00
|
|
|
/*
|
|
|
|
* This is a workaround for VHT-enabled STAs which break the spec
|
|
|
|
* and have the VHT-MCS Rx map filled in with value 3 for all eight
|
|
|
|
* spacial streams, an example is AR9462.
|
|
|
|
*
|
|
|
|
* As per spec, in section 22.1.1 Introduction to the VHT PHY
|
|
|
|
* A VHT STA shall support at least single spactial stream VHT-MCSs
|
|
|
|
* 0 to 7 (transmit and receive) in all supported channel widths.
|
|
|
|
*/
|
|
|
|
if (vht_cap->vht_mcs.rx_mcs_map == cpu_to_le16(0xFFFF)) {
|
|
|
|
vht_cap->vht_supported = false;
|
|
|
|
sdata_info(sdata, "Ignoring VHT IE from %pM due to invalid rx_mcs_map\n",
|
|
|
|
sta->addr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-03-01 12:07:48 +00:00
|
|
|
/* finally set up the bandwidth */
|
2012-12-27 17:55:36 +00:00
|
|
|
switch (vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
|
|
|
|
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
|
|
|
|
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ:
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_160;
|
2012-12-27 17:55:36 +00:00
|
|
|
break;
|
|
|
|
default:
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_80;
|
2018-08-31 08:31:19 +00:00
|
|
|
|
|
|
|
if (!(vht_cap->vht_mcs.tx_highest &
|
|
|
|
cpu_to_le16(IEEE80211_VHT_EXT_NSS_BW_CAPABLE)))
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this is non-zero, then it does support 160 MHz after all,
|
|
|
|
* in one form or the other. We don't distinguish here (or even
|
|
|
|
* above) between 160 and 80+80 yet.
|
|
|
|
*/
|
|
|
|
if (cap_info & IEEE80211_VHT_CAP_EXT_NSS_BW_MASK)
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_160;
|
2012-12-27 17:55:36 +00:00
|
|
|
}
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->sta.deflink.bandwidth = ieee80211_sta_cur_vht_bw(sta);
|
2015-12-13 13:41:05 +00:00
|
|
|
|
|
|
|
switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
|
|
|
|
case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
|
|
|
|
sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_11454;
|
|
|
|
break;
|
|
|
|
case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
|
|
|
|
sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_7991;
|
|
|
|
break;
|
|
|
|
case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
|
|
|
|
default:
|
|
|
|
sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_3895;
|
|
|
|
break;
|
|
|
|
}
|
2013-02-07 10:47:44 +00:00
|
|
|
}
|
|
|
|
|
2022-02-14 16:30:02 +00:00
|
|
|
/* FIXME: move this to some better location - parses HE/EHT now */
|
2014-12-14 09:05:51 +00:00
|
|
|
enum ieee80211_sta_rx_bandwidth ieee80211_sta_cap_rx_bw(struct sta_info *sta)
|
2013-02-07 10:47:44 +00:00
|
|
|
{
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
struct ieee80211_sta_vht_cap *vht_cap = &sta->sta.deflink.vht_cap;
|
|
|
|
struct ieee80211_sta_he_cap *he_cap = &sta->sta.deflink.he_cap;
|
|
|
|
struct ieee80211_sta_eht_cap *eht_cap = &sta->sta.deflink.eht_cap;
|
2014-12-14 09:05:51 +00:00
|
|
|
u32 cap_width;
|
2013-02-07 10:47:44 +00:00
|
|
|
|
2020-01-31 11:12:41 +00:00
|
|
|
if (he_cap->has_he) {
|
2022-02-14 16:30:02 +00:00
|
|
|
u8 info;
|
|
|
|
|
|
|
|
if (eht_cap->has_eht &&
|
|
|
|
sta->sdata->vif.bss_conf.chandef.chan->band ==
|
|
|
|
NL80211_BAND_6GHZ) {
|
|
|
|
info = eht_cap->eht_cap_elem.phy_cap_info[0];
|
|
|
|
|
|
|
|
if (info & IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ)
|
|
|
|
return IEEE80211_STA_RX_BW_320;
|
|
|
|
}
|
|
|
|
|
|
|
|
info = he_cap->he_cap_elem.phy_cap_info[0];
|
2020-01-31 11:12:41 +00:00
|
|
|
|
|
|
|
if (sta->sdata->vif.bss_conf.chandef.chan->band ==
|
|
|
|
NL80211_BAND_2GHZ) {
|
|
|
|
if (info & IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_IN_2G)
|
|
|
|
return IEEE80211_STA_RX_BW_40;
|
|
|
|
else
|
|
|
|
return IEEE80211_STA_RX_BW_20;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (info & IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G ||
|
|
|
|
info & IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS80_MHZ_IN_5G)
|
|
|
|
return IEEE80211_STA_RX_BW_160;
|
|
|
|
else if (info & IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_80MHZ_IN_5G)
|
|
|
|
return IEEE80211_STA_RX_BW_80;
|
|
|
|
|
|
|
|
return IEEE80211_STA_RX_BW_20;
|
|
|
|
}
|
|
|
|
|
2014-12-14 09:05:51 +00:00
|
|
|
if (!vht_cap->vht_supported)
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
return sta->sta.deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 ?
|
2014-12-14 09:05:51 +00:00
|
|
|
IEEE80211_STA_RX_BW_40 :
|
|
|
|
IEEE80211_STA_RX_BW_20;
|
2013-02-07 10:47:44 +00:00
|
|
|
|
2014-12-14 09:05:51 +00:00
|
|
|
cap_width = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
|
|
|
|
|
|
|
|
if (cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ ||
|
|
|
|
cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
|
|
|
|
return IEEE80211_STA_RX_BW_160;
|
|
|
|
|
2019-08-30 11:40:57 +00:00
|
|
|
/*
|
|
|
|
* If this is non-zero, then it does support 160 MHz after all,
|
|
|
|
* in one form or the other. We don't distinguish here (or even
|
|
|
|
* above) between 160 and 80+80 yet.
|
|
|
|
*/
|
|
|
|
if (vht_cap->cap & IEEE80211_VHT_CAP_EXT_NSS_BW_MASK)
|
|
|
|
return IEEE80211_STA_RX_BW_160;
|
|
|
|
|
2014-12-14 09:05:51 +00:00
|
|
|
return IEEE80211_STA_RX_BW_80;
|
|
|
|
}
|
|
|
|
|
2016-03-02 21:28:32 +00:00
|
|
|
enum nl80211_chan_width ieee80211_sta_cap_chan_bw(struct sta_info *sta)
|
|
|
|
{
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
struct ieee80211_sta_vht_cap *vht_cap = &sta->sta.deflink.vht_cap;
|
2016-03-02 21:28:32 +00:00
|
|
|
u32 cap_width;
|
|
|
|
|
|
|
|
if (!vht_cap->vht_supported) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (!sta->sta.deflink.ht_cap.ht_supported)
|
2016-03-02 21:28:32 +00:00
|
|
|
return NL80211_CHAN_WIDTH_20_NOHT;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
return sta->sta.deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 ?
|
2016-03-02 21:28:32 +00:00
|
|
|
NL80211_CHAN_WIDTH_40 : NL80211_CHAN_WIDTH_20;
|
|
|
|
}
|
|
|
|
|
|
|
|
cap_width = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
|
|
|
|
|
|
|
|
if (cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ)
|
|
|
|
return NL80211_CHAN_WIDTH_160;
|
|
|
|
else if (cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
|
|
|
|
return NL80211_CHAN_WIDTH_80P80;
|
|
|
|
|
|
|
|
return NL80211_CHAN_WIDTH_80;
|
|
|
|
}
|
|
|
|
|
2018-03-27 13:46:17 +00:00
|
|
|
enum nl80211_chan_width
|
|
|
|
ieee80211_sta_rx_bw_to_chan_width(struct sta_info *sta)
|
|
|
|
{
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
enum ieee80211_sta_rx_bandwidth cur_bw = sta->sta.deflink.bandwidth;
|
|
|
|
struct ieee80211_sta_vht_cap *vht_cap = &sta->sta.deflink.vht_cap;
|
2018-03-27 13:46:17 +00:00
|
|
|
u32 cap_width;
|
|
|
|
|
|
|
|
switch (cur_bw) {
|
|
|
|
case IEEE80211_STA_RX_BW_20:
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (!sta->sta.deflink.ht_cap.ht_supported)
|
2018-03-27 13:46:17 +00:00
|
|
|
return NL80211_CHAN_WIDTH_20_NOHT;
|
|
|
|
else
|
|
|
|
return NL80211_CHAN_WIDTH_20;
|
|
|
|
case IEEE80211_STA_RX_BW_40:
|
|
|
|
return NL80211_CHAN_WIDTH_40;
|
|
|
|
case IEEE80211_STA_RX_BW_80:
|
|
|
|
return NL80211_CHAN_WIDTH_80;
|
|
|
|
case IEEE80211_STA_RX_BW_160:
|
|
|
|
cap_width =
|
|
|
|
vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
|
|
|
|
|
|
|
|
if (cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ)
|
|
|
|
return NL80211_CHAN_WIDTH_160;
|
|
|
|
|
|
|
|
return NL80211_CHAN_WIDTH_80P80;
|
|
|
|
default:
|
|
|
|
return NL80211_CHAN_WIDTH_20;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-02 21:28:32 +00:00
|
|
|
enum ieee80211_sta_rx_bandwidth
|
2014-12-14 09:05:51 +00:00
|
|
|
ieee80211_chan_width_to_rx_bw(enum nl80211_chan_width width)
|
|
|
|
{
|
|
|
|
switch (width) {
|
2013-02-07 10:47:44 +00:00
|
|
|
case NL80211_CHAN_WIDTH_20_NOHT:
|
|
|
|
case NL80211_CHAN_WIDTH_20:
|
2014-12-14 09:05:51 +00:00
|
|
|
return IEEE80211_STA_RX_BW_20;
|
2013-02-07 10:47:44 +00:00
|
|
|
case NL80211_CHAN_WIDTH_40:
|
2014-12-14 09:05:51 +00:00
|
|
|
return IEEE80211_STA_RX_BW_40;
|
|
|
|
case NL80211_CHAN_WIDTH_80:
|
|
|
|
return IEEE80211_STA_RX_BW_80;
|
2013-02-07 10:47:44 +00:00
|
|
|
case NL80211_CHAN_WIDTH_160:
|
|
|
|
case NL80211_CHAN_WIDTH_80P80:
|
2014-12-14 09:05:51 +00:00
|
|
|
return IEEE80211_STA_RX_BW_160;
|
2022-02-14 16:30:00 +00:00
|
|
|
case NL80211_CHAN_WIDTH_320:
|
|
|
|
return IEEE80211_STA_RX_BW_320;
|
2014-12-14 09:05:51 +00:00
|
|
|
default:
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return IEEE80211_STA_RX_BW_20;
|
2013-02-07 10:47:44 +00:00
|
|
|
}
|
2014-12-14 09:05:51 +00:00
|
|
|
}
|
|
|
|
|
2020-01-31 11:12:41 +00:00
|
|
|
/* FIXME: rename/move - this deals with everything not just VHT */
|
2014-12-14 09:05:51 +00:00
|
|
|
enum ieee80211_sta_rx_bandwidth ieee80211_sta_cur_vht_bw(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
enum ieee80211_sta_rx_bandwidth bw;
|
2015-06-10 17:42:59 +00:00
|
|
|
enum nl80211_chan_width bss_width = sdata->vif.bss_conf.chandef.width;
|
2014-12-14 09:05:51 +00:00
|
|
|
|
2015-06-10 17:42:59 +00:00
|
|
|
bw = ieee80211_sta_cap_rx_bw(sta);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
bw = min(bw, sta->deflink.cur_max_bandwidth);
|
2017-09-25 19:09:15 +00:00
|
|
|
|
|
|
|
/* Don't consider AP's bandwidth for TDLS peers, section 11.23.1 of
|
|
|
|
* IEEE80211-2016 specification makes higher bandwidth operation
|
|
|
|
* possible on the TDLS link if the peers have wider bandwidth
|
|
|
|
* capability.
|
mac80211: don't set set TDLS STA bandwidth wider than possible
When we set up a TDLS station, we set sta->sta.bandwidth solely based
on the capabilities, because the "what's the current bandwidth" check
is bypassed and only applied for other types of stations.
This leads to the unfortunate scenario that the sta->sta.bandwidth is
160 MHz if both stations support it, but we never actually configure
this bandwidth unless the AP is already using 160 MHz; even for wider
bandwidth support we only go up to 80 MHz (at least right now.)
For iwlwifi, this can also lead to firmware asserts, telling us that
we've configured the TX rates for a higher bandwidth than is actually
available due to the PHY configuration.
For non-TDLS, we check against the interface's requested bandwidth,
but we explicitly skip this check for TDLS to cope with the wider BW
case. Change this to
(a) still limit to the TDLS peer's own chandef, which gets factored
into the overall PHY configuration we request from the driver,
and
(b) limit it to when the TDLS peer is authorized, because it's only
factored into the channel context in this case.
Fixes: 504871e602d9 ("mac80211: fix bandwidth computation for TDLS peers")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.fcc7d29c4590.I11f77e9e25ddf871a3c8d5604650c763e2c5887a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-06 12:54:44 +00:00
|
|
|
*
|
|
|
|
* However, in this case, and only if the TDLS peer is authorized,
|
|
|
|
* limit to the tdls_chandef so that the configuration here isn't
|
|
|
|
* wider than what's actually requested on the channel context.
|
2017-09-25 19:09:15 +00:00
|
|
|
*/
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) &&
|
mac80211: don't set set TDLS STA bandwidth wider than possible
When we set up a TDLS station, we set sta->sta.bandwidth solely based
on the capabilities, because the "what's the current bandwidth" check
is bypassed and only applied for other types of stations.
This leads to the unfortunate scenario that the sta->sta.bandwidth is
160 MHz if both stations support it, but we never actually configure
this bandwidth unless the AP is already using 160 MHz; even for wider
bandwidth support we only go up to 80 MHz (at least right now.)
For iwlwifi, this can also lead to firmware asserts, telling us that
we've configured the TX rates for a higher bandwidth than is actually
available due to the PHY configuration.
For non-TDLS, we check against the interface's requested bandwidth,
but we explicitly skip this check for TDLS to cope with the wider BW
case. Change this to
(a) still limit to the TDLS peer's own chandef, which gets factored
into the overall PHY configuration we request from the driver,
and
(b) limit it to when the TDLS peer is authorized, because it's only
factored into the channel context in this case.
Fixes: 504871e602d9 ("mac80211: fix bandwidth computation for TDLS peers")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.fcc7d29c4590.I11f77e9e25ddf871a3c8d5604650c763e2c5887a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-06 12:54:44 +00:00
|
|
|
test_sta_flag(sta, WLAN_STA_TDLS_WIDER_BW) &&
|
|
|
|
test_sta_flag(sta, WLAN_STA_AUTHORIZED) &&
|
|
|
|
sta->tdls_chandef.chan)
|
|
|
|
bw = min(bw, ieee80211_chan_width_to_rx_bw(sta->tdls_chandef.width));
|
|
|
|
else
|
|
|
|
bw = min(bw, ieee80211_chan_width_to_rx_bw(bss_width));
|
2015-06-10 17:42:59 +00:00
|
|
|
|
2012-12-27 17:55:36 +00:00
|
|
|
return bw;
|
2012-10-10 11:33:04 +00:00
|
|
|
}
|
2012-12-27 17:26:42 +00:00
|
|
|
|
|
|
|
void ieee80211_sta_set_rx_nss(struct sta_info *sta)
|
|
|
|
{
|
2022-02-14 16:30:04 +00:00
|
|
|
u8 ht_rx_nss = 0, vht_rx_nss = 0, he_rx_nss = 0, eht_rx_nss = 0, rx_nss;
|
2021-01-05 03:08:39 +00:00
|
|
|
bool support_160;
|
2012-12-27 17:26:42 +00:00
|
|
|
|
|
|
|
/* if we received a notification already don't overwrite it */
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.rx_nss)
|
2012-12-27 17:26:42 +00:00
|
|
|
return;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.eht_cap.has_eht) {
|
2022-02-14 16:30:04 +00:00
|
|
|
int i;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
const u8 *rx_nss_mcs = (void *)&sta->sta.deflink.eht_cap.eht_mcs_nss_supp;
|
2022-02-14 16:30:04 +00:00
|
|
|
|
|
|
|
/* get the max nss for EHT over all possible bandwidths and mcs */
|
|
|
|
for (i = 0; i < sizeof(struct ieee80211_eht_mcs_nss_supp); i++)
|
|
|
|
eht_rx_nss = max_t(u8, eht_rx_nss,
|
|
|
|
u8_get_bits(rx_nss_mcs[i],
|
|
|
|
IEEE80211_EHT_MCS_NSS_RX));
|
|
|
|
}
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.he_cap.has_he) {
|
2020-01-31 11:12:45 +00:00
|
|
|
int i;
|
|
|
|
u8 rx_mcs_80 = 0, rx_mcs_160 = 0;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
const struct ieee80211_sta_he_cap *he_cap = &sta->sta.deflink.he_cap;
|
2020-01-31 11:12:45 +00:00
|
|
|
u16 mcs_160_map =
|
|
|
|
le16_to_cpu(he_cap->he_mcs_nss_supp.rx_mcs_160);
|
|
|
|
u16 mcs_80_map = le16_to_cpu(he_cap->he_mcs_nss_supp.rx_mcs_80);
|
|
|
|
|
|
|
|
for (i = 7; i >= 0; i--) {
|
|
|
|
u8 mcs_160 = (mcs_160_map >> (2 * i)) & 3;
|
|
|
|
|
2022-02-02 08:49:41 +00:00
|
|
|
if (mcs_160 != IEEE80211_HE_MCS_NOT_SUPPORTED) {
|
2020-01-31 11:12:45 +00:00
|
|
|
rx_mcs_160 = i + 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for (i = 7; i >= 0; i--) {
|
|
|
|
u8 mcs_80 = (mcs_80_map >> (2 * i)) & 3;
|
|
|
|
|
2022-02-02 08:49:41 +00:00
|
|
|
if (mcs_80 != IEEE80211_HE_MCS_NOT_SUPPORTED) {
|
2020-01-31 11:12:45 +00:00
|
|
|
rx_mcs_80 = i + 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-01-05 03:08:39 +00:00
|
|
|
support_160 = he_cap->he_cap_elem.phy_cap_info[0] &
|
|
|
|
IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G;
|
|
|
|
|
|
|
|
if (support_160)
|
|
|
|
he_rx_nss = min(rx_mcs_80, rx_mcs_160);
|
|
|
|
else
|
|
|
|
he_rx_nss = rx_mcs_80;
|
2020-01-31 11:12:45 +00:00
|
|
|
}
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.ht_cap.ht_supported) {
|
|
|
|
if (sta->sta.deflink.ht_cap.mcs.rx_mask[0])
|
2012-12-27 17:26:42 +00:00
|
|
|
ht_rx_nss++;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.ht_cap.mcs.rx_mask[1])
|
2012-12-27 17:26:42 +00:00
|
|
|
ht_rx_nss++;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.ht_cap.mcs.rx_mask[2])
|
2012-12-27 17:26:42 +00:00
|
|
|
ht_rx_nss++;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.ht_cap.mcs.rx_mask[3])
|
2012-12-27 17:26:42 +00:00
|
|
|
ht_rx_nss++;
|
|
|
|
/* FIXME: consider rx_highest? */
|
|
|
|
}
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.vht_cap.vht_supported) {
|
2012-12-27 17:26:42 +00:00
|
|
|
int i;
|
|
|
|
u16 rx_mcs_map;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
rx_mcs_map = le16_to_cpu(sta->sta.deflink.vht_cap.vht_mcs.rx_mcs_map);
|
2012-12-27 17:26:42 +00:00
|
|
|
|
|
|
|
for (i = 7; i >= 0; i--) {
|
|
|
|
u8 mcs = (rx_mcs_map >> (2 * i)) & 3;
|
|
|
|
|
|
|
|
if (mcs != IEEE80211_VHT_MCS_NOT_SUPPORTED) {
|
|
|
|
vht_rx_nss = i + 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* FIXME: consider rx_highest? */
|
|
|
|
}
|
|
|
|
|
2020-01-31 11:12:45 +00:00
|
|
|
rx_nss = max(vht_rx_nss, ht_rx_nss);
|
|
|
|
rx_nss = max(he_rx_nss, rx_nss);
|
2022-02-14 16:30:04 +00:00
|
|
|
rx_nss = max(eht_rx_nss, rx_nss);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->sta.deflink.rx_nss = max_t(u8, 1, rx_nss);
|
2012-12-27 17:26:42 +00:00
|
|
|
}
|
2012-12-27 17:55:36 +00:00
|
|
|
|
2014-02-03 13:44:44 +00:00
|
|
|
u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta, u8 opmode,
|
2016-04-12 13:56:15 +00:00
|
|
|
enum nl80211_band band)
|
2012-12-27 17:55:36 +00:00
|
|
|
{
|
|
|
|
enum ieee80211_sta_rx_bandwidth new_bw;
|
2018-01-31 10:54:50 +00:00
|
|
|
struct sta_opmode_info sta_opmode = {};
|
2012-12-27 17:55:36 +00:00
|
|
|
u32 changed = 0;
|
|
|
|
u8 nss;
|
|
|
|
|
|
|
|
/* ignore - no support for BF yet */
|
|
|
|
if (opmode & IEEE80211_OPMODE_NOTIF_RX_NSS_TYPE_BF)
|
2014-02-03 13:44:44 +00:00
|
|
|
return 0;
|
2012-12-27 17:55:36 +00:00
|
|
|
|
|
|
|
nss = opmode & IEEE80211_OPMODE_NOTIF_RX_NSS_MASK;
|
|
|
|
nss >>= IEEE80211_OPMODE_NOTIF_RX_NSS_SHIFT;
|
|
|
|
nss += 1;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (sta->sta.deflink.rx_nss != nss) {
|
|
|
|
sta->sta.deflink.rx_nss = nss;
|
2018-01-31 10:54:50 +00:00
|
|
|
sta_opmode.rx_nss = nss;
|
2012-12-27 17:55:36 +00:00
|
|
|
changed |= IEEE80211_RC_NSS_CHANGED;
|
2018-01-31 10:54:50 +00:00
|
|
|
sta_opmode.changed |= STA_OPMODE_N_SS_CHANGED;
|
2012-12-27 17:55:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
switch (opmode & IEEE80211_OPMODE_NOTIF_CHANWIDTH_MASK) {
|
|
|
|
case IEEE80211_OPMODE_NOTIF_CHANWIDTH_20MHZ:
|
2020-03-26 13:09:32 +00:00
|
|
|
/* ignore IEEE80211_OPMODE_NOTIF_BW_160_80P80 must not be set */
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_20;
|
2012-12-27 17:55:36 +00:00
|
|
|
break;
|
|
|
|
case IEEE80211_OPMODE_NOTIF_CHANWIDTH_40MHZ:
|
2020-03-26 13:09:32 +00:00
|
|
|
/* ignore IEEE80211_OPMODE_NOTIF_BW_160_80P80 must not be set */
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_40;
|
2012-12-27 17:55:36 +00:00
|
|
|
break;
|
|
|
|
case IEEE80211_OPMODE_NOTIF_CHANWIDTH_80MHZ:
|
2020-03-26 13:09:32 +00:00
|
|
|
if (opmode & IEEE80211_OPMODE_NOTIF_BW_160_80P80)
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_160;
|
2020-03-26 13:09:32 +00:00
|
|
|
else
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_80;
|
2012-12-27 17:55:36 +00:00
|
|
|
break;
|
|
|
|
case IEEE80211_OPMODE_NOTIF_CHANWIDTH_160MHZ:
|
2020-03-26 13:09:32 +00:00
|
|
|
/* legacy only, no longer used by newer spec */
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
sta->deflink.cur_max_bandwidth = IEEE80211_STA_RX_BW_160;
|
2012-12-27 17:55:36 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
new_bw = ieee80211_sta_cur_vht_bw(sta);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 15:41:23 +00:00
|
|
|
if (new_bw != sta->sta.deflink.bandwidth) {
|
|
|
|
sta->sta.deflink.bandwidth = new_bw;
|
2018-03-27 13:46:17 +00:00
|
|
|
sta_opmode.bw = ieee80211_sta_rx_bw_to_chan_width(sta);
|
2013-06-10 07:34:14 +00:00
|
|
|
changed |= IEEE80211_RC_BW_CHANGED;
|
2018-01-31 10:54:50 +00:00
|
|
|
sta_opmode.changed |= STA_OPMODE_MAX_BW_CHANGED;
|
2012-12-27 17:55:36 +00:00
|
|
|
}
|
|
|
|
|
2018-01-31 10:54:50 +00:00
|
|
|
if (sta_opmode.changed)
|
|
|
|
cfg80211_sta_opmode_change_notify(sdata->dev, sta->addr,
|
|
|
|
&sta_opmode, GFP_KERNEL);
|
|
|
|
|
2014-02-03 13:44:44 +00:00
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
2015-12-08 14:04:31 +00:00
|
|
|
void ieee80211_process_mu_groups(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct ieee80211_mgmt *mgmt)
|
|
|
|
{
|
|
|
|
struct ieee80211_bss_conf *bss_conf = &sdata->vif.bss_conf;
|
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 11:26:44 +00:00
|
|
|
if (!sdata->vif.bss_conf.mu_mimo_owner)
|
2015-12-08 14:04:31 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (!memcmp(mgmt->u.action.u.vht_group_notif.position,
|
|
|
|
bss_conf->mu_group.position, WLAN_USER_POSITION_LEN) &&
|
|
|
|
!memcmp(mgmt->u.action.u.vht_group_notif.membership,
|
|
|
|
bss_conf->mu_group.membership, WLAN_MEMBERSHIP_LEN))
|
|
|
|
return;
|
|
|
|
|
2016-02-03 19:52:23 +00:00
|
|
|
memcpy(bss_conf->mu_group.membership,
|
|
|
|
mgmt->u.action.u.vht_group_notif.membership,
|
|
|
|
WLAN_MEMBERSHIP_LEN);
|
|
|
|
memcpy(bss_conf->mu_group.position,
|
|
|
|
mgmt->u.action.u.vht_group_notif.position,
|
|
|
|
WLAN_USER_POSITION_LEN);
|
2015-12-08 14:04:31 +00:00
|
|
|
|
2022-05-24 08:55:56 +00:00
|
|
|
ieee80211_link_info_change_notify(sdata, 0, BSS_CHANGED_MU_GROUPS);
|
2015-12-08 14:04:31 +00:00
|
|
|
}
|
|
|
|
|
2016-02-16 10:48:17 +00:00
|
|
|
void ieee80211_update_mu_groups(struct ieee80211_vif *vif,
|
|
|
|
const u8 *membership, const u8 *position)
|
|
|
|
{
|
2016-02-16 10:48:18 +00:00
|
|
|
struct ieee80211_bss_conf *bss_conf = &vif->bss_conf;
|
2016-02-16 10:48:17 +00:00
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 11:26:44 +00:00
|
|
|
if (WARN_ON_ONCE(!vif->bss_conf.mu_mimo_owner))
|
2016-02-16 10:48:17 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
memcpy(bss_conf->mu_group.membership, membership, WLAN_MEMBERSHIP_LEN);
|
|
|
|
memcpy(bss_conf->mu_group.position, position, WLAN_USER_POSITION_LEN);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ieee80211_update_mu_groups);
|
|
|
|
|
2014-02-03 13:44:44 +00:00
|
|
|
void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta, u8 opmode,
|
2016-04-12 13:56:15 +00:00
|
|
|
enum nl80211_band band)
|
2014-02-03 13:44:44 +00:00
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band];
|
|
|
|
|
2015-12-08 14:04:36 +00:00
|
|
|
u32 changed = __ieee80211_vht_handle_opmode(sdata, sta, opmode, band);
|
2014-02-03 13:44:44 +00:00
|
|
|
|
2016-10-20 06:52:50 +00:00
|
|
|
if (changed > 0) {
|
|
|
|
ieee80211_recalc_min_chandef(sdata);
|
2012-12-27 17:55:36 +00:00
|
|
|
rate_control_rate_update(local, sband, sta, changed);
|
2016-10-20 06:52:50 +00:00
|
|
|
}
|
2012-12-27 17:55:36 +00:00
|
|
|
}
|
2015-08-06 21:47:33 +00:00
|
|
|
|
|
|
|
void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
|
|
|
|
u16 vht_mask[NL80211_VHT_NSS_MAX])
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u16 mask, cap = le16_to_cpu(vht_cap);
|
|
|
|
|
|
|
|
for (i = 0; i < NL80211_VHT_NSS_MAX; i++) {
|
|
|
|
mask = (cap >> i * 2) & IEEE80211_VHT_MCS_NOT_SUPPORTED;
|
|
|
|
switch (mask) {
|
|
|
|
case IEEE80211_VHT_MCS_SUPPORT_0_7:
|
|
|
|
vht_mask[i] = 0x00FF;
|
|
|
|
break;
|
|
|
|
case IEEE80211_VHT_MCS_SUPPORT_0_8:
|
|
|
|
vht_mask[i] = 0x01FF;
|
|
|
|
break;
|
|
|
|
case IEEE80211_VHT_MCS_SUPPORT_0_9:
|
|
|
|
vht_mask[i] = 0x03FF;
|
|
|
|
break;
|
|
|
|
case IEEE80211_VHT_MCS_NOT_SUPPORTED:
|
|
|
|
default:
|
|
|
|
vht_mask[i] = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|