2023-12-19 17:42:08

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 01/13] wifi: cfg80211: reg: Support P2P operation on DFS channels

From: Andrei Otcheretianski <[email protected]>

FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to
operate on DFS channels while they operate under the control of a
concurrent DFS master. For example, it is possible to have a P2P GO on a
DFS channel as long as BSS connection is active on the same channel.
Allow such operation by adding additional regulatory flags to indicate
DFS concurrent channels and capable devices. Add the required
relaxations in DFS regulatory checks.

Signed-off-by: Andrei Otcheretianski <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: fix the wrong email addresses
---
include/net/cfg80211.h | 2 +
include/uapi/linux/nl80211.h | 16 ++++++
net/wireless/chan.c | 94 +++++++++++++++++++++++++++++++++---
net/wireless/nl80211.c | 3 ++
net/wireless/reg.c | 2 +
5 files changed, 110 insertions(+), 7 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 602960dafe0f..868c50b516b8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -117,6 +117,7 @@ struct wiphy;
* This may be due to the driver or due to regulatory bandwidth
* restrictions.
* @IEEE80211_CHAN_NO_EHT: EHT operation is not permitted on this channel.
+ * @IEEE80211_CHAN_DFS_CONCURRENT: See %NL80211_RRF_DFS_CONCURRENT
*/
enum ieee80211_channel_flags {
IEEE80211_CHAN_DISABLED = 1<<0,
@@ -140,6 +141,7 @@ enum ieee80211_channel_flags {
IEEE80211_CHAN_16MHZ = 1<<18,
IEEE80211_CHAN_NO_320MHZ = 1<<19,
IEEE80211_CHAN_NO_EHT = 1<<20,
+ IEEE80211_CHAN_DFS_CONCURRENT = 1<<21,
};

#define IEEE80211_CHAN_NO_HT40 \
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index a682b54bd3ba..466da830e65f 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4256,6 +4256,10 @@ enum nl80211_wmm_rule {
* in current regulatory domain.
* @NL80211_FREQUENCY_ATTR_PSD: Power spectral density (in dBm) that
* is allowed on this channel in current regulatory domain.
+ * @NL80211_FREQUENCY_ATTR_DFS_CONCURRENT: Operation on this channel is
+ * allowed for peer-to-peer or adhoc communication under the control
+ * of a DFS master which operates on the same channel (FCC-594280 D01
+ * Section B.3). Should be used together with %NL80211_RRF_DFS only.
* @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
* currently defined
* @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
@@ -4295,6 +4299,7 @@ enum nl80211_frequency_attr {
NL80211_FREQUENCY_ATTR_NO_320MHZ,
NL80211_FREQUENCY_ATTR_NO_EHT,
NL80211_FREQUENCY_ATTR_PSD,
+ NL80211_FREQUENCY_ATTR_DFS_CONCURRENT,

/* keep last */
__NL80211_FREQUENCY_ATTR_AFTER_LAST,
@@ -4500,6 +4505,10 @@ enum nl80211_sched_scan_match_attr {
* @NL80211_RRF_NO_320MHZ: 320MHz operation not allowed
* @NL80211_RRF_NO_EHT: EHT operation not allowed
* @NL80211_RRF_PSD: Ruleset has power spectral density value
+ * @NL80211_RRF_DFS_CONCURRENT: Operation on this channel is allowed for
+ peer-to-peer or adhoc communication under the control of a DFS master
+ which operates on the same channel (FCC-594280 D01 Section B.3).
+ Should be used together with %NL80211_RRF_DFS only.
*/
enum nl80211_reg_rule_flags {
NL80211_RRF_NO_OFDM = 1<<0,
@@ -4521,6 +4530,7 @@ enum nl80211_reg_rule_flags {
NL80211_RRF_NO_320MHZ = 1<<18,
NL80211_RRF_NO_EHT = 1<<19,
NL80211_RRF_PSD = 1<<20,
+ NL80211_RRF_DFS_CONCURRENT = 1<<21,
};

#define NL80211_RRF_PASSIVE_SCAN NL80211_RRF_NO_IR
@@ -6492,6 +6502,11 @@ enum nl80211_feature_flags {
* @NL80211_EXT_FEATURE_OWE_OFFLOAD_AP: Driver/Device wants to do OWE DH IE
* handling in AP mode.
*
+ * @NL80211_EXT_FEATURE_DFS_CONCURRENT: The device supports peer-to-peer or
+ * ad hoc operation on DFS channels under the control of a concurrent
+ * DFS master on the same channel as described in FCC-594280 D01
+ * (Section B.3). This, for example, allows P2P GO and P2P clients to
+ * operate on DFS channels as long as there's a concurrent BSS connection.
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
*/
@@ -6565,6 +6580,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_AUTH_AND_DEAUTH_RANDOM_TA,
NL80211_EXT_FEATURE_OWE_OFFLOAD,
NL80211_EXT_FEATURE_OWE_OFFLOAD_AP,
+ NL80211_EXT_FEATURE_DFS_CONCURRENT,

/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index dfb4893421d7..ceb9174c5c3d 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -515,9 +515,83 @@ static u32 cfg80211_get_end_freq(u32 center_freq,
return end_freq;
}

+static bool
+cfg80211_dfs_permissive_check_wdev(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct wireless_dev *wdev,
+ struct ieee80211_channel *chan)
+{
+ unsigned int link_id;
+
+ for_each_valid_link(wdev, link_id) {
+ struct ieee80211_channel *other_chan = NULL;
+ struct cfg80211_chan_def chandef = {};
+ int ret;
+
+ /* In order to avoid daisy chaining only allow BSS STA */
+ if (wdev->iftype != NL80211_IFTYPE_STATION ||
+ !wdev->links[link_id].client.current_bss)
+ continue;
+
+ other_chan =
+ wdev->links[link_id].client.current_bss->pub.channel;
+
+ if (!other_chan)
+ continue;
+
+ if (chan == other_chan)
+ return true;
+
+ /* continue if we can't get the channel */
+ ret = rdev_get_channel(rdev, wdev, link_id, &chandef);
+ if (ret)
+ continue;
+
+ if (cfg80211_is_sub_chan(&chandef, chan, false))
+ return true;
+ }
+
+ return false;
+}
+
+/*
+ * Check if P2P GO is allowed to operate on a DFS channel
+ */
+static bool cfg80211_dfs_permissive_chan(struct wiphy *wiphy,
+ enum nl80211_iftype iftype,
+ struct ieee80211_channel *chan)
+{
+ struct wireless_dev *wdev;
+ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
+
+ lockdep_assert_held(&rdev->wiphy.mtx);
+
+ if (!wiphy_ext_feature_isset(&rdev->wiphy,
+ NL80211_EXT_FEATURE_DFS_CONCURRENT) ||
+ !(chan->flags & IEEE80211_CHAN_DFS_CONCURRENT))
+ return false;
+
+ /* only valid for P2P GO */
+ if (iftype != NL80211_IFTYPE_P2P_GO)
+ return false;
+
+ /*
+ * Allow only if there's a concurrent BSS
+ */
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+ bool ret = cfg80211_dfs_permissive_check_wdev(rdev, iftype,
+ wdev, chan);
+ if (ret)
+ return ret;
+ }
+
+ return false;
+}
+
static int cfg80211_get_chans_dfs_required(struct wiphy *wiphy,
u32 center_freq,
- u32 bandwidth)
+ u32 bandwidth,
+ enum nl80211_iftype iftype)
{
struct ieee80211_channel *c;
u32 freq, start_freq, end_freq;
@@ -530,9 +604,11 @@ static int cfg80211_get_chans_dfs_required(struct wiphy *wiphy,
if (!c)
return -EINVAL;

- if (c->flags & IEEE80211_CHAN_RADAR)
+ if (c->flags & IEEE80211_CHAN_RADAR &&
+ !cfg80211_dfs_permissive_chan(wiphy, iftype, c))
return 1;
}
+
return 0;
}

@@ -558,7 +634,7 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy,

ret = cfg80211_get_chans_dfs_required(wiphy,
ieee80211_chandef_to_khz(chandef),
- width);
+ width, iftype);
if (ret < 0)
return ret;
else if (ret > 0)
@@ -569,7 +645,7 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy,

ret = cfg80211_get_chans_dfs_required(wiphy,
MHZ_TO_KHZ(chandef->center_freq2),
- width);
+ width, iftype);
if (ret < 0)
return ret;
else if (ret > 0)
@@ -1337,15 +1413,19 @@ static bool _cfg80211_reg_can_beacon(struct wiphy *wiphy,
bool check_no_ir)
{
bool res;
- u32 prohibited_flags = IEEE80211_CHAN_DISABLED |
- IEEE80211_CHAN_RADAR;
+ u32 prohibited_flags = IEEE80211_CHAN_DISABLED;
+ int dfs_required;

trace_cfg80211_reg_can_beacon(wiphy, chandef, iftype, check_no_ir);

if (check_no_ir)
prohibited_flags |= IEEE80211_CHAN_NO_IR;

- if (cfg80211_chandef_dfs_required(wiphy, chandef, iftype) > 0 &&
+ dfs_required = cfg80211_chandef_dfs_required(wiphy, chandef, iftype);
+ if (dfs_required != 0)
+ prohibited_flags |= IEEE80211_CHAN_RADAR;
+
+ if (dfs_required > 0 &&
cfg80211_chandef_dfs_available(wiphy, chandef)) {
/* We can skip IEEE80211_CHAN_NO_IR if chandef dfs available */
prohibited_flags = IEEE80211_CHAN_DISABLED;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7ea1cb632952..ff2c63d59bb5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1201,6 +1201,9 @@ static int nl80211_msg_put_channel(struct sk_buff *msg, struct wiphy *wiphy,
if ((chan->flags & IEEE80211_CHAN_NO_EHT) &&
nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_EHT))
goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_DFS_CONCURRENT) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_DFS_CONCURRENT))
+ goto nla_put_failure;
}

if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2ef4f6cc7a32..9a61b3322fd2 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1593,6 +1593,8 @@ static u32 map_regdom_flags(u32 rd_flags)
channel_flags |= IEEE80211_CHAN_NO_320MHZ;
if (rd_flags & NL80211_RRF_NO_EHT)
channel_flags |= IEEE80211_CHAN_NO_EHT;
+ if (rd_flags & NL80211_RRF_DFS_CONCURRENT)
+ channel_flags |= IEEE80211_CHAN_DFS_CONCURRENT;
if (rd_flags & NL80211_RRF_PSD)
channel_flags |= IEEE80211_CHAN_PSD;
return channel_flags;
--
2.34.1



2023-12-19 17:42:13

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 02/13] wifi: cfg80211: Schedule regulatory check on BSS STA channel change

From: Andrei Otcheretianski <[email protected]>

Due to different relaxation policies it may be needed to re-check
channels after a BSS station interface is disconnected or performed a
channel switch.

Signed-off-by: Andrei Otcheretianski <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
include/net/cfg80211.h | 11 +++++++++++
net/wireless/nl80211.c | 15 +++++++++++++++
net/wireless/reg.c | 2 +-
net/wireless/reg.h | 5 +++++
net/wireless/sme.c | 2 ++
5 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 868c50b516b8..d8150d8b13e5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -9375,6 +9375,17 @@ bool cfg80211_valid_disable_subchannel_bitmap(u16 *bitmap,
* case disconnect instead.
* Also note that the wdev mutex must be held.
*/
+
void cfg80211_links_removed(struct net_device *dev, u16 link_mask);

+/**
+ * cfg80211_schedule_channels_check - schedule regulatory check if needed
+ * @wdev: the wireless device to check
+ *
+ * In case the device supports NO_IR or DFS relaxations, schedule regulatory
+ * channels check, as previous concurrent operation conditions may not
+ * hold anymore.
+ */
+void cfg80211_schedule_channels_check(struct wireless_dev *wdev);
+
#endif /* __NET_CFG80211_H */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ff2c63d59bb5..f64005d62b19 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -19457,6 +19457,7 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
break;
}

+ cfg80211_schedule_channels_check(wdev);
cfg80211_sched_dfs_chan_update(rdev);

nl80211_ch_switch_notify(rdev, dev, link_id, chandef, GFP_KERNEL,
@@ -20214,6 +20215,20 @@ void cfg80211_update_owe_info_event(struct net_device *netdev,
}
EXPORT_SYMBOL(cfg80211_update_owe_info_event);

+void cfg80211_schedule_channels_check(struct wireless_dev *wdev)
+{
+ struct wiphy *wiphy = wdev->wiphy;
+
+ /* Schedule channels check if NO_IR or DFS relaxations are supported */
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ (wiphy_ext_feature_isset(wiphy,
+ NL80211_EXT_FEATURE_DFS_CONCURRENT) ||
+ (IS_ENABLED(CONFIG_CFG80211_REG_RELAX_NO_IR) &&
+ wiphy->regulatory_flags & REGULATORY_ENABLE_RELAX_NO_IR)))
+ reg_check_channels();
+}
+EXPORT_SYMBOL(cfg80211_schedule_channels_check);
+
/* initialisation/exit functions */

int __init nl80211_init(void)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9a61b3322fd2..44684df64734 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2480,7 +2480,7 @@ static void reg_check_chans_work(struct work_struct *work)
rtnl_unlock();
}

-static void reg_check_channels(void)
+void reg_check_channels(void)
{
/*
* Give usermode a chance to do something nicer (move to another
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index a703e53c23ee..a02ef5609f52 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -181,6 +181,11 @@ bool reg_dfs_domain_same(struct wiphy *wiphy1, struct wiphy *wiphy2);
*/
int reg_reload_regdb(void);

+/**
+ * reg_check_channels - schedule regulatory enforcement
+ */
+void reg_check_channels(void);
+
extern const u8 shipped_regdb_certs[];
extern unsigned int shipped_regdb_certs_len;
extern const u8 extra_regdb_certs[];
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index acfe66da7109..195c8532734b 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1394,6 +1394,8 @@ void __cfg80211_disconnected(struct net_device *dev, const u8 *ie,
#endif

schedule_work(&cfg80211_disconnect_work);
+
+ cfg80211_schedule_channels_check(wdev);
}

void cfg80211_disconnected(struct net_device *dev, u16 reason,
--
2.34.1


2023-12-19 17:42:18

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 03/13] wifi: mac80211: Schedule regulatory channels check on bandwith change

From: Andrei Otcheretianski <[email protected]>

Some devices may support concurrent DFS operation which relies on the
BSS channel width for its relaxations. Notify cfg80211 about BW change
so it can schedule regulatory checks.

Signed-off-by: Andrei Otcheretianski <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
net/mac80211/mlme.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 40a4fbfff530..fe0be3e5731b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -598,6 +598,7 @@ static int ieee80211_config_bw(struct ieee80211_link_data *link,
return ret;
}

+ cfg80211_schedule_channels_check(&sdata->wdev);
return 0;
}

--
2.34.1


2023-12-19 17:42:26

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 04/13] wifi: mac80211_hwsim: Add custom reg for DFS concurrent

From: Andrei Otcheretianski <[email protected]>

Add custom regulatory that marks DFS channels as DFS_CONCURRENT.

Signed-off-by: Andrei Otcheretianski <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
drivers/net/wireless/virtual/mac80211_hwsim.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index c7b4414cc6c3..3816b0d335f0 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -190,10 +190,25 @@ static const struct ieee80211_regdomain hwsim_world_regdom_custom_03 = {
}
};

+static const struct ieee80211_regdomain hwsim_world_regdom_custom_04 = {
+ .n_reg_rules = 6,
+ .alpha2 = "99",
+ .reg_rules = {
+ REG_RULE(2412 - 10, 2462 + 10, 40, 0, 20, 0),
+ REG_RULE(2484 - 10, 2484 + 10, 40, 0, 20, 0),
+ REG_RULE(5150 - 10, 5240 + 10, 80, 0, 30, 0),
+ REG_RULE(5260 - 10, 5320 + 10, 80, 0, 30,
+ NL80211_RRF_DFS_CONCURRENT | NL80211_RRF_DFS),
+ REG_RULE(5745 - 10, 5825 + 10, 80, 0, 30, 0),
+ REG_RULE(5855 - 10, 5925 + 10, 80, 0, 33, 0),
+ }
+};
+
static const struct ieee80211_regdomain *hwsim_world_regdom_custom[] = {
&hwsim_world_regdom_custom_01,
&hwsim_world_regdom_custom_02,
&hwsim_world_regdom_custom_03,
+ &hwsim_world_regdom_custom_04,
};

struct hwsim_vif_priv {
@@ -5288,6 +5303,10 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
schedule_timeout_interruptible(1);
}

+ /* TODO: Add param */
+ wiphy_ext_feature_set(hw->wiphy,
+ NL80211_EXT_FEATURE_DFS_CONCURRENT);
+
if (param->no_vif)
ieee80211_hw_set(hw, NO_AUTO_VIF);

--
2.34.1


2023-12-19 17:42:27

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

From: Mukesh Sisodiya <[email protected]>

UHB AP send supported power type(LPI, SP, VLP)
in beacon and probe response IE and STA should
connect to these AP only if their regulatory support
the AP power type.

Beacon/Probe response are reported to userspace
with reason "STA regulatory not supporting to connect to AP
based on transmitted power type" and it should
not connect to AP.

Signed-off-by: Mukesh Sisodiya <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
include/linux/ieee80211.h | 1 +
include/net/cfg80211.h | 6 ++++++
include/uapi/linux/nl80211.h | 13 ++++++++++++
net/wireless/nl80211.c | 6 ++++++
net/wireless/reg.c | 4 ++++
net/wireless/scan.c | 38 ++++++++++++++++++++++++++++++++++++
6 files changed, 68 insertions(+)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 5e5ea216f341..e484d9d10630 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2720,6 +2720,7 @@ static inline bool ieee80211_he_capa_size_ok(const u8 *data, u8 len)

#define IEEE80211_6GHZ_CTRL_REG_LPI_AP 0
#define IEEE80211_6GHZ_CTRL_REG_SP_AP 1
+#define IEEE80211_6GHZ_CTRL_REG_VLP_AP 2

/**
* struct ieee80211_he_6ghz_oper - HE 6 GHz operation Information field
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d8150d8b13e5..427a83c78c8c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -118,6 +118,10 @@ struct wiphy;
* restrictions.
* @IEEE80211_CHAN_NO_EHT: EHT operation is not permitted on this channel.
* @IEEE80211_CHAN_DFS_CONCURRENT: See %NL80211_RRF_DFS_CONCURRENT
+ * @IEEE80211_CHAN_NO_UHB_VLP_CLIENT: Client connection with VLP AP
+ * not permitted using this channel
+ * @IEEE80211_CHAN_NO_UHB_AFC_CLIENT: Client connection with AFC AP
+ * not permitted using this channel
*/
enum ieee80211_channel_flags {
IEEE80211_CHAN_DISABLED = 1<<0,
@@ -142,6 +146,8 @@ enum ieee80211_channel_flags {
IEEE80211_CHAN_NO_320MHZ = 1<<19,
IEEE80211_CHAN_NO_EHT = 1<<20,
IEEE80211_CHAN_DFS_CONCURRENT = 1<<21,
+ IEEE80211_CHAN_NO_UHB_VLP_CLIENT= 1<<22,
+ IEEE80211_CHAN_NO_UHB_AFC_CLIENT= 1<<23,
};

#define IEEE80211_CHAN_NO_HT40 \
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 466da830e65f..1ccdcae24372 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4260,6 +4260,10 @@ enum nl80211_wmm_rule {
* allowed for peer-to-peer or adhoc communication under the control
* of a DFS master which operates on the same channel (FCC-594280 D01
* Section B.3). Should be used together with %NL80211_RRF_DFS only.
+ * @NL80211_FREQUENCY_ATTR_NO_UHB_VLP_CLIENT: Client connection to VLP AP
+ * not allowed using this channel
+ * @NL80211_FREQUENCY_ATTR_NO_UHB_AFC_CLIENT: Client connection to AFC AP
+ * not allowed using this channel
* @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
* currently defined
* @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
@@ -4300,6 +4304,8 @@ enum nl80211_frequency_attr {
NL80211_FREQUENCY_ATTR_NO_EHT,
NL80211_FREQUENCY_ATTR_PSD,
NL80211_FREQUENCY_ATTR_DFS_CONCURRENT,
+ NL80211_FREQUENCY_ATTR_NO_UHB_VLP_CLIENT,
+ NL80211_FREQUENCY_ATTR_NO_UHB_AFC_CLIENT,

/* keep last */
__NL80211_FREQUENCY_ATTR_AFTER_LAST,
@@ -4509,6 +4515,8 @@ enum nl80211_sched_scan_match_attr {
peer-to-peer or adhoc communication under the control of a DFS master
which operates on the same channel (FCC-594280 D01 Section B.3).
Should be used together with %NL80211_RRF_DFS only.
+ * @NL80211_RRF_NO_UHB_VLP_CLIENT: Client connection to VLP AP not allowed
+ * @NL80211_RRF_NO_UHB_AFC_CLIENT: Client connection to AFC AP not allowed
*/
enum nl80211_reg_rule_flags {
NL80211_RRF_NO_OFDM = 1<<0,
@@ -4531,6 +4539,8 @@ enum nl80211_reg_rule_flags {
NL80211_RRF_NO_EHT = 1<<19,
NL80211_RRF_PSD = 1<<20,
NL80211_RRF_DFS_CONCURRENT = 1<<21,
+ NL80211_RRF_NO_UHB_VLP_CLIENT = 1<<22,
+ NL80211_RRF_NO_UHB_AFC_CLIENT = 1<<23,
};

#define NL80211_RRF_PASSIVE_SCAN NL80211_RRF_NO_IR
@@ -5086,9 +5096,12 @@ enum nl80211_bss_use_for {
* BSS isn't possible
* @NL80211_BSS_CANNOT_USE_NSTR_NONPRIMARY: NSTR nonprimary links aren't
* supported by the device, and this BSS entry represents one.
+ * @NL80211_BSS_CANNOT_USE_UHB_PWR_MISMATCH: STA is not supporting
+ * the AP power type (SP, VLP, AP) that the AP uses.
*/
enum nl80211_bss_cannot_use_reasons {
NL80211_BSS_CANNOT_USE_NSTR_NONPRIMARY = 1 << 0,
+ NL80211_BSS_CANNOT_USE_UHB_PWR_MISMATCH = 1 << 1,
};

/**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f64005d62b19..299f2622b00d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1204,6 +1204,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg, struct wiphy *wiphy,
if ((chan->flags & IEEE80211_CHAN_DFS_CONCURRENT) &&
nla_put_flag(msg, NL80211_FREQUENCY_ATTR_DFS_CONCURRENT))
goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_NO_UHB_VLP_CLIENT) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_UHB_VLP_CLIENT))
+ goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_NO_UHB_AFC_CLIENT) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_UHB_AFC_CLIENT))
+ goto nla_put_failure;
}

if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 44684df64734..2741b626919a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1595,6 +1595,10 @@ static u32 map_regdom_flags(u32 rd_flags)
channel_flags |= IEEE80211_CHAN_NO_EHT;
if (rd_flags & NL80211_RRF_DFS_CONCURRENT)
channel_flags |= IEEE80211_CHAN_DFS_CONCURRENT;
+ if (rd_flags & NL80211_RRF_NO_UHB_VLP_CLIENT)
+ channel_flags |= IEEE80211_CHAN_NO_UHB_VLP_CLIENT;
+ if (rd_flags & NL80211_RRF_NO_UHB_AFC_CLIENT)
+ channel_flags |= IEEE80211_CHAN_NO_UHB_AFC_CLIENT;
if (rd_flags & NL80211_RRF_PSD)
channel_flags |= IEEE80211_CHAN_PSD;
return channel_flags;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 3d260c99c348..a601f1c7f835 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -2848,6 +2848,36 @@ cfg80211_inform_bss_data(struct wiphy *wiphy,
}
EXPORT_SYMBOL(cfg80211_inform_bss_data);

+static bool cfg80211_uhb_power_type_valid(const u8 *ie,
+ size_t ielen,
+ const u32 flags)
+{
+ const struct element *tmp;
+ struct ieee80211_he_operation *he_oper;
+
+ tmp = cfg80211_find_ext_elem(WLAN_EID_EXT_HE_OPERATION, ie, ielen);
+ if (tmp && tmp->datalen >= sizeof(*he_oper) + 1) {
+ const struct ieee80211_he_6ghz_oper *he_6ghz_oper;
+
+ he_oper = (void *)&tmp->data[1];
+ he_6ghz_oper = ieee80211_he_6ghz_oper(he_oper);
+
+ if (!he_6ghz_oper)
+ return false;
+
+ switch (u8_get_bits(he_6ghz_oper->control,
+ IEEE80211_HE_6GHZ_OPER_CTRL_REG_INFO)) {
+ case IEEE80211_6GHZ_CTRL_REG_LPI_AP:
+ return true;
+ case IEEE80211_6GHZ_CTRL_REG_SP_AP:
+ return !(flags & IEEE80211_CHAN_NO_UHB_AFC_CLIENT);
+ case IEEE80211_6GHZ_CTRL_REG_VLP_AP:
+ return !(flags & IEEE80211_CHAN_NO_UHB_VLP_CLIENT);
+ }
+ }
+ return false;
+}
+
/* cfg80211_inform_bss_width_frame helper */
static struct cfg80211_bss *
cfg80211_inform_single_bss_frame_data(struct wiphy *wiphy,
@@ -2906,6 +2936,14 @@ cfg80211_inform_single_bss_frame_data(struct wiphy *wiphy,
if (!channel)
return NULL;

+ if (channel->band == NL80211_BAND_6GHZ &&
+ !cfg80211_uhb_power_type_valid(variable, ielen, channel->flags)) {
+ data->restrict_use = 1;
+ data->use_for = 0;
+ data->cannot_use_reasons =
+ NL80211_BSS_CANNOT_USE_UHB_PWR_MISMATCH;
+ }
+
if (ext) {
const struct ieee80211_s1g_bcn_compat_ie *compat;
const struct element *elem;
--
2.34.1


2023-12-19 17:42:32

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 06/13] wifi: mac80211: rework RX timestamp flags

From: Johannes Berg <[email protected]>

We only have a single flag free, and before using that for
another mactime flag, instead refactor the mactime flags
to use a 2-bit field.

Signed-off-by: Johannes Berg <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Reviewed-by: Benjamin Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses and fix ath code
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
include/net/mac80211.h | 13 +++++++++----
net/mac80211/ieee80211_i.h | 5 +----
net/mac80211/util.c | 16 ++++++++++------
4 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index fa0f598ed6bf..7d28ae5453cf 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1295,7 +1295,7 @@ static void ath10k_htt_rx_h_ppdu(struct ath10k *ar,
status->encoding = RX_ENC_LEGACY;
status->bw = RATE_INFO_BW_20;

- status->flag &= ~RX_FLAG_MACTIME_END;
+ status->flag &= ~RX_FLAG_MACTIME;
status->flag |= RX_FLAG_NO_SIGNAL_VAL;

status->flag &= ~(RX_FLAG_AMPDU_IS_LAST);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 77a71b1396b1..00274d1cdeeb 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1362,6 +1362,9 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* the frame.
* @RX_FLAG_FAILED_PLCP_CRC: Set this flag if the PCLP check failed on
* the frame.
+ * @RX_FLAG_MACTIME: The timestamp passed in the RX status (@mactime
+ * field) is valid if this field is non-zero, and the position
+ * where the timestamp was sampled depends on the value.
* @RX_FLAG_MACTIME_START: The timestamp passed in the RX status (@mactime
* field) is valid and contains the time the first symbol of the MPDU
* was received. This is useful in monitor mode and for proper IBSS
@@ -1441,12 +1444,12 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
RX_FLAG_DECRYPTED = BIT(1),
- RX_FLAG_MACTIME_PLCP_START = BIT(2),
+ RX_FLAG_ONLY_MONITOR = BIT(2),
RX_FLAG_MMIC_STRIPPED = BIT(3),
RX_FLAG_IV_STRIPPED = BIT(4),
RX_FLAG_FAILED_FCS_CRC = BIT(5),
RX_FLAG_FAILED_PLCP_CRC = BIT(6),
- RX_FLAG_MACTIME_START = BIT(7),
+ /* one free bit at 7 */
RX_FLAG_NO_SIGNAL_VAL = BIT(8),
RX_FLAG_AMPDU_DETAILS = BIT(9),
RX_FLAG_PN_VALIDATED = BIT(10),
@@ -1455,8 +1458,10 @@ enum mac80211_rx_flags {
RX_FLAG_AMPDU_IS_LAST = BIT(13),
RX_FLAG_AMPDU_DELIM_CRC_ERROR = BIT(14),
RX_FLAG_AMPDU_DELIM_CRC_KNOWN = BIT(15),
- RX_FLAG_MACTIME_END = BIT(16),
- RX_FLAG_ONLY_MONITOR = BIT(17),
+ RX_FLAG_MACTIME = BIT(16) | BIT(17),
+ RX_FLAG_MACTIME_PLCP_START = 1 << 16,
+ RX_FLAG_MACTIME_START = 2 << 16,
+ RX_FLAG_MACTIME_END = 3 << 16,
RX_FLAG_SKIP_MONITOR = BIT(18),
RX_FLAG_AMSDU_MORE = BIT(19),
RX_FLAG_RADIOTAP_TLV_AT_END = BIT(20),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 29312f6638a1..938f4d255668 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1775,10 +1775,7 @@ static inline bool txq_has_queue(struct ieee80211_txq *txq)
static inline bool
ieee80211_have_rx_timestamp(struct ieee80211_rx_status *status)
{
- WARN_ON_ONCE(status->flag & RX_FLAG_MACTIME_START &&
- status->flag & RX_FLAG_MACTIME_END);
- return !!(status->flag & (RX_FLAG_MACTIME_START | RX_FLAG_MACTIME_END |
- RX_FLAG_MACTIME_PLCP_START));
+ return status->flag & RX_FLAG_MACTIME;
}

void ieee80211_vif_inc_num_mcast(struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index ed680120d5a7..643c54855be6 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -4176,6 +4176,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
unsigned int mpdu_offset)
{
u64 ts = status->mactime;
+ bool mactime_plcp_start;
struct rate_info ri;
u16 rate;
u8 n_ltf;
@@ -4183,6 +4184,9 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
if (WARN_ON(!ieee80211_have_rx_timestamp(status)))
return 0;

+ mactime_plcp_start = (status->flag & RX_FLAG_MACTIME) ==
+ RX_FLAG_MACTIME_PLCP_START;
+
memset(&ri, 0, sizeof(ri));

ri.bw = status->bw;
@@ -4197,7 +4201,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
if (status->enc_flags & RX_ENC_FLAG_SHORT_GI)
ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
/* TODO/FIXME: is this right? handle other PPDUs */
- if (status->flag & RX_FLAG_MACTIME_PLCP_START) {
+ if (mactime_plcp_start) {
mpdu_offset += 2;
ts += 36;
}
@@ -4214,7 +4218,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
* See P802.11ax_D6.0, section 27.3.4 for
* VHT PPDU format.
*/
- if (status->flag & RX_FLAG_MACTIME_PLCP_START) {
+ if (mactime_plcp_start) {
mpdu_offset += 2;
ts += 36;

@@ -4238,7 +4242,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
* See P802.11REVmd_D3.0, section 19.3.2 for
* HT PPDU format.
*/
- if (status->flag & RX_FLAG_MACTIME_PLCP_START) {
+ if (mactime_plcp_start) {
mpdu_offset += 2;
if (status->enc_flags & RX_ENC_FLAG_HT_GF)
ts += 24;
@@ -4266,7 +4270,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
* See P802.11REVmd_D3.0, section 21.3.2 for
* VHT PPDU format.
*/
- if (status->flag & RX_FLAG_MACTIME_PLCP_START) {
+ if (mactime_plcp_start) {
mpdu_offset += 2;
ts += 36;

@@ -4288,7 +4292,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
sband = local->hw.wiphy->bands[status->band];
ri.legacy = sband->bitrates[status->rate_idx].bitrate;

- if (status->flag & RX_FLAG_MACTIME_PLCP_START) {
+ if (mactime_plcp_start) {
if (status->band == NL80211_BAND_5GHZ) {
ts += 20;
mpdu_offset += 2;
@@ -4310,7 +4314,7 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
return 0;

/* rewind from end of MPDU */
- if (status->flag & RX_FLAG_MACTIME_END)
+ if ((status->flag & RX_FLAG_MACTIME) == RX_FLAG_MACTIME_END)
ts -= mpdu_len * 8 * 10 / rate;

ts += mpdu_offset * 8 * 10 / rate;
--
2.34.1


2023-12-19 17:42:34

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 07/13] wifi: mac80211: allow 64-bit radiotap timestamps

From: Johannes Berg <[email protected]>

When reporting the radiotap timestamp, the mactime field is
usually unused, we take the data from the device_timestamp.
However, there can be cases where the radiotap timestamp is
better reported as a 64-bit value, so since the mactime is
free, add a flag to support using the mactime as a 64-bit
radiotap timestamp.

Signed-off-by: Johannes Berg <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Reviewed-by: Benjamin Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
include/net/mac80211.h | 7 ++++++-
net/mac80211/rx.c | 13 +++++++++++--
2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 00274d1cdeeb..58328d0c1cf5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1374,6 +1374,11 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* (including FCS) was received.
* @RX_FLAG_MACTIME_PLCP_START: The timestamp passed in the RX status (@mactime
* field) is valid and contains the time the SYNC preamble was received.
+ * @RX_FLAG_MACTIME_IS_RTAP_TS64: The timestamp passed in the RX status @mactime
+ * is only for use in the radiotap timestamp header, not otherwise a valid
+ * @mactime value. Note this is a separate flag so that we continue to see
+ * %RX_FLAG_MACTIME as unset. Also note that in this case the timestamp is
+ * reported to be 64 bits wide, not just 32.
* @RX_FLAG_NO_SIGNAL_VAL: The signal strength value is not present.
* Valid only for data frames (mainly A-MPDU)
* @RX_FLAG_AMPDU_DETAILS: A-MPDU details are known, in particular the reference
@@ -1449,7 +1454,7 @@ enum mac80211_rx_flags {
RX_FLAG_IV_STRIPPED = BIT(4),
RX_FLAG_FAILED_FCS_CRC = BIT(5),
RX_FLAG_FAILED_PLCP_CRC = BIT(6),
- /* one free bit at 7 */
+ RX_FLAG_MACTIME_IS_RTAP_TS64 = BIT(7),
RX_FLAG_NO_SIGNAL_VAL = BIT(8),
RX_FLAG_AMPDU_DETAILS = BIT(9),
RX_FLAG_PN_VALIDATED = BIT(10),
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bbfdcb0ade72..a57c8272c1dc 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -566,7 +566,8 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,

if (local->hw.radiotap_timestamp.units_pos >= 0) {
u16 accuracy = 0;
- u8 flags = IEEE80211_RADIOTAP_TIMESTAMP_FLAG_32BIT;
+ u8 flags;
+ u64 ts;

rthdr->it_present |=
cpu_to_le32(BIT(IEEE80211_RADIOTAP_TIMESTAMP));
@@ -575,7 +576,15 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
while ((pos - (u8 *)rthdr) & 7)
pos++;

- put_unaligned_le64(status->device_timestamp, pos);
+ if (status->flag & RX_FLAG_MACTIME_IS_RTAP_TS64) {
+ flags = IEEE80211_RADIOTAP_TIMESTAMP_FLAG_64BIT;
+ ts = status->mactime;
+ } else {
+ flags = IEEE80211_RADIOTAP_TIMESTAMP_FLAG_32BIT;
+ ts = status->device_timestamp;
+ }
+
+ put_unaligned_le64(ts, pos);
pos += sizeof(u64);

if (local->hw.radiotap_timestamp.accuracy >= 0) {
--
2.34.1


2023-12-19 17:42:41

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 08/13] wifi: cfg80211: free beacon_ies when overridden from hidden BSS

From: Benjamin Berg <[email protected]>

This is a more of a cosmetic fix. The branch will only be taken if
proberesp_ies is set, which implies that beacon_ies is not set unless we
are connected to an AP that just did a channel switch. And, in that case
we should have found the BSS in the internal storage to begin with.

Signed-off-by: Benjamin Berg <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
net/wireless/scan.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index a601f1c7f835..68ba446067ac 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -1871,8 +1871,12 @@ __cfg80211_bss_update(struct cfg80211_registered_device *rdev,
list_add(&new->hidden_list,
&hidden->hidden_list);
hidden->refcount++;
+
+ ies = (void *)rcu_dereference(new->pub.beacon_ies);
rcu_assign_pointer(new->pub.beacon_ies,
hidden->pub.beacon_ies);
+ if (ies)
+ kfree_rcu(ies, rcu_head);
}
} else {
/*
--
2.34.1


2023-12-19 17:42:49

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 09/13] wifi: cfg80211: ensure cfg80211_bss_update frees IEs on error

From: Benjamin Berg <[email protected]>

cfg80211_bss_update is expected to consume the IEs that are passed into
it in the temporary internal BSS. This did not happen in some error
cases (which are also WARN_ON paths), so change the code to use a common
label and use that everywhere.

Signed-off-by: Benjamin Berg <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
net/wireless/scan.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 68ba446067ac..f7fd7ea0e935 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -1818,15 +1818,15 @@ __cfg80211_bss_update(struct cfg80211_registered_device *rdev,
bool signal_valid, unsigned long ts)
{
struct cfg80211_internal_bss *found = NULL;
+ struct cfg80211_bss_ies *ies;

if (WARN_ON(!tmp->pub.channel))
- return NULL;
+ goto free_ies;

tmp->ts = ts;

- if (WARN_ON(!rcu_access_pointer(tmp->pub.ies))) {
- return NULL;
- }
+ if (WARN_ON(!rcu_access_pointer(tmp->pub.ies)))
+ goto free_ies;

found = rb_find_bss(rdev, tmp, BSS_CMP_REGULAR);

@@ -1836,7 +1836,6 @@ __cfg80211_bss_update(struct cfg80211_registered_device *rdev,
} else {
struct cfg80211_internal_bss *new;
struct cfg80211_internal_bss *hidden;
- struct cfg80211_bss_ies *ies;

/*
* create a copy -- the "res" variable that is passed in
@@ -1845,15 +1844,8 @@ __cfg80211_bss_update(struct cfg80211_registered_device *rdev,
*/
new = kzalloc(sizeof(*new) + rdev->wiphy.bss_priv_size,
GFP_ATOMIC);
- if (!new) {
- ies = (void *)rcu_dereference(tmp->pub.beacon_ies);
- if (ies)
- kfree_rcu(ies, rcu_head);
- ies = (void *)rcu_dereference(tmp->pub.proberesp_ies);
- if (ies)
- kfree_rcu(ies, rcu_head);
- return NULL;
- }
+ if (!new)
+ goto free_ies;
memcpy(new, tmp, sizeof(*new));
new->refcount = 1;
INIT_LIST_HEAD(&new->hidden_list);
@@ -1913,6 +1905,16 @@ __cfg80211_bss_update(struct cfg80211_registered_device *rdev,
bss_ref_get(rdev, found);

return found;
+
+free_ies:
+ ies = (void *)rcu_dereference(tmp->pub.beacon_ies);
+ if (ies)
+ kfree_rcu(ies, rcu_head);
+ ies = (void *)rcu_dereference(tmp->pub.proberesp_ies);
+ if (ies)
+ kfree_rcu(ies, rcu_head);
+
+ return NULL;
}

struct cfg80211_internal_bss *
--
2.34.1


2023-12-19 17:42:50

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 10/13] wifi: cfg80211: avoid double free if updating BSS fails

From: Benjamin Berg <[email protected]>

cfg80211_update_known_bss will always consume the passed IEs. As such,
cfg80211_update_assoc_bss_entry also needs to always set the pointers to
NULL so that no double free can occur.

Note that hitting this would probably require being connected to a
hidden BSS which is then doing a channel switch while also switching to
be not hidden anymore at the same time.

Signed-off-by: Benjamin Berg <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
net/wireless/scan.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index f7fd7ea0e935..cf2131671eb6 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -3194,10 +3194,9 @@ void cfg80211_update_assoc_bss_entry(struct wireless_dev *wdev,

if (new) {
/* to save time, update IEs for transmitting bss only */
- if (cfg80211_update_known_bss(rdev, cbss, new, false)) {
- new->pub.proberesp_ies = NULL;
- new->pub.beacon_ies = NULL;
- }
+ cfg80211_update_known_bss(rdev, cbss, new, false);
+ new->pub.proberesp_ies = NULL;
+ new->pub.beacon_ies = NULL;

list_for_each_entry_safe(nontrans_bss, tmp,
&new->pub.nontrans_list,
--
2.34.1


2023-12-19 17:43:03

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 13/13] wifi: mac80211_hwsim: support HE 40MHz in 2.4Ghz band

We are missing the flag that indicates that capability
of 40MHz bandwidth support in HE on the LB.
Add it.

Signed-off-by: Miri Korenblit <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
---
v2: Fix wrong email addresses
---
drivers/net/wireless/virtual/mac80211_hwsim.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index 3816b0d335f0..a84340c2075f 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -4044,6 +4044,8 @@ static const struct ieee80211_sband_iftype_data sband_capa_2ghz[] = {
IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_EXT_3,
.mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMSDU_IN_AMPDU,
+ .phy_cap_info[0] =
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_IN_2G,
.phy_cap_info[1] =
IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
@@ -4149,6 +4151,8 @@ static const struct ieee80211_sband_iftype_data sband_capa_2ghz[] = {
IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_EXT_3,
.mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMSDU_IN_AMPDU,
+ .phy_cap_info[0] =
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_IN_2G,
.phy_cap_info[1] =
IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
@@ -4252,6 +4256,8 @@ static const struct ieee80211_sband_iftype_data sband_capa_2ghz[] = {
IEEE80211_HE_MAC_CAP3_OMI_CONTROL |
IEEE80211_HE_MAC_CAP3_MAX_AMPDU_LEN_EXP_EXT_3,
.mac_cap_info[4] = IEEE80211_HE_MAC_CAP4_AMSDU_IN_AMPDU,
+ .phy_cap_info[0] =
+ IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_IN_2G,
.phy_cap_info[1] =
IEEE80211_HE_PHY_CAP1_PREAMBLE_PUNC_RX_MASK |
IEEE80211_HE_PHY_CAP1_DEVICE_CLASS_A |
--
2.34.1


2023-12-19 17:43:03

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 12/13] wifi: mac80211: add a driver callback to check active_links

During ieee80211_set_active_links() we do (among the others):
1. Call drv_change_vif_links() with both old_active and new_active
2. Unassign the chanctx for the removed link(s) (if any)
3. Assign chanctx to the added link(s) (if any)
4. Call drv_change_vif_links() with the new_active links bitmap

The problem here is that during step #1 the driver doesn't know whether
we will activate multiple links simultaneously or are just doing a link
switch, so it can't check there if multiple links are supported/enabled.
(Some of the drivers might enable/disable this option dynamically)

And during step #3, in which the driver already knows that,
returning an error code (for example when multiple links are not
supported or disabled), will cause a warning, and we will still complete
the transition to the new_active links.
(It is hard to undo things in that stage, since we released channels etc.)

Therefore add a driver callback to check if the desired new_active links
will be supported by the driver or not. This callback will be called
in the beginning of ieee80211_set_active_links() so we won't do anything
before we are sure it is supported.

Signed-off-by: Miri Korenblit <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
---
v2: Fix wrong email addresses
---
include/net/mac80211.h | 5 +++++
net/mac80211/driver-ops.h | 20 ++++++++++++++++++++
net/mac80211/link.c | 3 +++
net/mac80211/trace.h | 25 +++++++++++++++++++++++++
4 files changed, 53 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 58328d0c1cf5..7cb60a5a7904 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4281,6 +4281,8 @@ struct ieee80211_prep_tx_info {
* disable background CAC/radar detection.
* @net_fill_forward_path: Called from .ndo_fill_forward_path in order to
* resolve a path for hardware flow offloading
+ * @can_activate_links: Checks if a specific active_links bitmap is
+ * supported by the driver.
* @change_vif_links: Change the valid links on an interface, note that while
* removing the old link information is still valid (link_conf pointer),
* but may immediately disappear after the function returns. The old or
@@ -4661,6 +4663,9 @@ struct ieee80211_ops {
struct ieee80211_sta *sta,
struct net_device_path_ctx *ctx,
struct net_device_path *path);
+ bool (*can_activate_links)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u16 active_links);
int (*change_vif_links)(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
u16 old_links, u16 new_links,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index fecf92f06da7..39ac2c0d6190 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1661,6 +1661,26 @@ static inline int drv_net_setup_tc(struct ieee80211_local *local,
return ret;
}

+static inline bool drv_can_activate_links(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ u16 active_links)
+{
+ bool ret = true;
+
+ lockdep_assert_wiphy(local->hw.wiphy);
+
+ if (!check_sdata_in_driver(sdata))
+ return false;
+
+ trace_drv_can_activate_links(local, sdata, active_links);
+ if (local->ops->can_activate_links)
+ ret = local->ops->can_activate_links(&local->hw, &sdata->vif,
+ active_links);
+ trace_drv_return_bool(local, ret);
+
+ return ret;
+}
+
int drv_change_vif_links(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
u16 old_links, u16 new_links,
diff --git a/net/mac80211/link.c b/net/mac80211/link.c
index bf7bd880d062..d4f86955afa6 100644
--- a/net/mac80211/link.c
+++ b/net/mac80211/link.c
@@ -444,6 +444,9 @@ int ieee80211_set_active_links(struct ieee80211_vif *vif, u16 active_links)

lockdep_assert_wiphy(local->hw.wiphy);

+ if (!drv_can_activate_links(local, sdata, active_links))
+ return -EINVAL;
+
old_active = sdata->vif.active_links;
if (old_active & active_links) {
/*
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 032718d5b298..06835ed4c44f 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -2512,6 +2512,31 @@ TRACE_EVENT(drv_net_setup_tc,
)
);

+TRACE_EVENT(drv_can_activate_links,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ u16 active_links),
+
+ TP_ARGS(local, sdata, active_links),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(u16, active_links)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->active_links = active_links;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT VIF_PR_FMT " requested active_links:0x%04x\n",
+ LOCAL_PR_ARG, VIF_PR_ARG, __entry->active_links
+ )
+);
+
TRACE_EVENT(drv_change_vif_links,
TP_PROTO(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
--
2.34.1


2023-12-19 17:52:00

by Miri Korenblit

[permalink] [raw]
Subject: [PATCH v2 11/13] wifi: mac80211: fix advertised TTLM scheduling

From: Ayala Beker <[email protected]>

Handle a case of time overflow, where the switch time might
be smaller than the partial TSF in the beacon.
Additionally, apply advertised TTLM earlier in order to be
ready on time on the newly activated links.

Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping")
Signed-off-by: Ayala Beker <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
---
v2: Fix wrong email addresses
---
net/mac80211/mlme.c | 49 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index fe0be3e5731b..b526ce589d4d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -43,6 +43,9 @@
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_ASSOC_MAX_TRIES 3

+#define IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS msecs_to_jiffies(100)
+#define IEEE80211_ADV_TTLM_ST_UNDERFLOW 0xff00
+
static int max_nullfunc_tries = 2;
module_param(max_nullfunc_tries, int, 0644);
MODULE_PARM_DESC(max_nullfunc_tries,
@@ -5965,6 +5968,13 @@ ieee80211_parse_adv_t2l(struct ieee80211_sub_if_data *sdata,
pos++;

ttlm_info->switch_time = get_unaligned_le16(pos);
+
+ /* Since ttlm_info->switch_time == 0 means no switch time, bump it
+ * by 1.
+ */
+ if (!ttlm_info->switch_time)
+ ttlm_info->switch_time = 1;
+
pos += 2;

if (control & IEEE80211_TTLM_CONTROL_EXPECTED_DUR_PRESENT) {
@@ -6059,25 +6069,46 @@ static void ieee80211_process_adv_ttlm(struct ieee80211_sub_if_data *sdata,
}

if (ttlm_info.switch_time) {
- u32 st_us, delay = 0;
- u32 ts_l26 = beacon_ts & GENMASK(25, 0);
+ u16 beacon_ts_tu, st_tu, delay;
+ u32 delay_jiffies;
+ u64 mask;

/* The t2l map switch time is indicated with a partial
- * TSF value, convert it to TSF and calc the delay
- * to the start time.
+ * TSF value (bits 10 to 25), get the partial beacon TS
+ * as well, and calc the delay to the start time.
+ */
+ mask = GENMASK_ULL(25, 10);
+ beacon_ts_tu = (beacon_ts & mask) >> 10;
+ st_tu = ttlm_info.switch_time;
+ delay = st_tu - beacon_ts_tu;
+
+ /*
+ * If the switch time is far in the future, then it
+ * could also be the previous switch still being
+ * announced.
+ * We can simply ignore it for now, if it is a future
+ * switch the AP will continue to announce it anyway.
+ */
+ if (delay > IEEE80211_ADV_TTLM_ST_UNDERFLOW)
+ return;
+
+ delay_jiffies = TU_TO_JIFFIES(delay);
+
+ /* Link switching can take time, so schedule it
+ * 100ms before to be ready on time
*/
- st_us = ieee80211_tu_to_usec(ttlm_info.switch_time);
- if (st_us > ts_l26)
- delay = st_us - ts_l26;
+ if (delay_jiffies > IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS)
+ delay_jiffies -=
+ IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS;
else
- continue;
+ delay_jiffies = 0;

sdata->u.mgd.ttlm_info = ttlm_info;
wiphy_delayed_work_cancel(sdata->local->hw.wiphy,
&sdata->u.mgd.ttlm_work);
wiphy_delayed_work_queue(sdata->local->hw.wiphy,
&sdata->u.mgd.ttlm_work,
- usecs_to_jiffies(delay));
+ delay_jiffies);
return;
}
}
--
2.34.1


2023-12-19 22:14:07

by Jeff Johnson

[permalink] [raw]
Subject: Re: [PATCH v2 01/13] wifi: cfg80211: reg: Support P2P operation on DFS channels

On 12/20/2023 3:41 AM, Miri Korenblit wrote:
> From: Andrei Otcheretianski <[email protected]>
>
> FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to
> operate on DFS channels while they operate under the control of a
> concurrent DFS master. For example, it is possible to have a P2P GO on a
> DFS channel as long as BSS connection is active on the same channel.
> Allow such operation by adding additional regulatory flags to indicate
> DFS concurrent channels and capable devices. Add the required
> relaxations in DFS regulatory checks.
>
> Signed-off-by: Andrei Otcheretianski <[email protected]>
> Reviewed-by: Gregory Greenman <[email protected]>
> Signed-off-by: Miri Korenblit <[email protected]>

Curious if there will be a companion change to wireless-regdb.git to
allow this flag to be set in db.txt?

Looks like we haven't been very good about adding support for new
nl80211_reg_rule_flags to dbparse.py.

2023-12-19 22:14:20

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH v2 01/13] wifi: cfg80211: reg: Support P2P operation on DFS channels

On Tue, 2023-12-19 at 14:03 -0800, Jeff Johnson wrote:
> On 12/20/2023 3:41 AM, Miri Korenblit wrote:
> > From: Andrei Otcheretianski <[email protected]>
> >
> > FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to
> > operate on DFS channels while they operate under the control of a
> > concurrent DFS master. For example, it is possible to have a P2P GO on a
> > DFS channel as long as BSS connection is active on the same channel.
> > Allow such operation by adding additional regulatory flags to indicate
> > DFS concurrent channels and capable devices. Add the required
> > relaxations in DFS regulatory checks.
> >
> > Signed-off-by: Andrei Otcheretianski <[email protected]>
> > Reviewed-by: Gregory Greenman <[email protected]>
> > Signed-off-by: Miri Korenblit <[email protected]>
>
> Curious if there will be a companion change to wireless-regdb.git to
> allow this flag to be set in db.txt?
>
> Looks like we haven't been very good about adding support for new
> nl80211_reg_rule_flags to dbparse.py.
>
Yeah, we really haven't, and it seems that nobody really cares any more,
since all the new devices have self-managed regulatory? Certainly that's
true for our device, so even if we were to add a flag and all to
everything related to the regdb, it'd have no effect for Intel NICs. So
the interest is pretty low ...

johannes

2023-12-19 22:41:45

by Jeff Johnson

[permalink] [raw]
Subject: Re: [PATCH v2 06/13] wifi: mac80211: rework RX timestamp flags

On 12/20/2023 3:41 AM, Miri Korenblit wrote:
> From: Johannes Berg <[email protected]>
>
> We only have a single flag free, and before using that for
> another mactime flag, instead refactor the mactime flags
> to use a 2-bit field.
>
> Signed-off-by: Johannes Berg <[email protected]>
> Reviewed-by: Gregory Greenman <[email protected]>
> Reviewed-by: Benjamin Berg <[email protected]>
> Signed-off-by: Miri Korenblit <[email protected]>
> ---
> v2: Fix wrong email addresses and fix ath code
> ---
> drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
> include/net/mac80211.h | 13 +++++++++----
> net/mac80211/ieee80211_i.h | 5 +----
> net/mac80211/util.c | 16 ++++++++++------
> 4 files changed, 21 insertions(+), 15 deletions(-)
..snip..
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 29312f6638a1..938f4d255668 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1775,10 +1775,7 @@ static inline bool txq_has_queue(struct ieee80211_txq *txq)
> static inline bool
> ieee80211_have_rx_timestamp(struct ieee80211_rx_status *status)
> {
> - WARN_ON_ONCE(status->flag & RX_FLAG_MACTIME_START &&
> - status->flag & RX_FLAG_MACTIME_END);
> - return !!(status->flag & (RX_FLAG_MACTIME_START | RX_FLAG_MACTIME_END |
> - RX_FLAG_MACTIME_PLCP_START));
> + return status->flag & RX_FLAG_MACTIME;

curious why you dropped the !!
now the code can return a value that doesn't map to the true/false bool
enums


2023-12-19 22:43:11

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH v2 06/13] wifi: mac80211: rework RX timestamp flags

On Tue, 2023-12-19 at 14:41 -0800, Jeff Johnson wrote:
>
> > static inline bool
> > ieee80211_have_rx_timestamp(struct ieee80211_rx_status *status)
> > {
> > - WARN_ON_ONCE(status->flag & RX_FLAG_MACTIME_START &&
> > - status->flag & RX_FLAG_MACTIME_END);
> > - return !!(status->flag & (RX_FLAG_MACTIME_START | RX_FLAG_MACTIME_END |
> > - RX_FLAG_MACTIME_PLCP_START));
> > + return status->flag & RX_FLAG_MACTIME;
>
> curious why you dropped the !!

Just a general cleanup I guess.

> now the code can return a value that doesn't map to the true/false bool
> enums

No, it cannot, at least not if 'bool' is implemented in a C99-compliant
way :) It's not actually an enum, it will return 0/1 in the machine
register even with this code.

johannes

2023-12-19 22:48:46

by Jeff Johnson

[permalink] [raw]
Subject: Re: [PATCH v2 13/13] wifi: mac80211_hwsim: support HE 40MHz in 2.4Ghz band

On 12/20/2023 3:41 AM, Miri Korenblit wrote:
> We are missing the flag that indicates that capability
> of 40MHz bandwidth support in HE on the LB.

Subject nit: s/Ghz/GHz/
Also consider adding a space between value and units of all frequency
references to conform to SI naming (which is also the format used by the
802.11 specifications).


2023-12-19 23:17:31

by Jeff Johnson

[permalink] [raw]
Subject: Re: [PATCH v2 06/13] wifi: mac80211: rework RX timestamp flags

On 12/19/2023 2:43 PM, Johannes Berg wrote:
> On Tue, 2023-12-19 at 14:41 -0800, Jeff Johnson wrote:
>> now the code can return a value that doesn't map to the true/false bool
>> enums
>
> No, it cannot, at least not if 'bool' is implemented in a C99-compliant
> way :) It's not actually an enum, it will return 0/1 in the machine
> register even with this code.

Today I learned something new. Guess I'm still carrying baggage from
pre-C99.

/jeff


2023-12-20 14:13:53

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH v2 01/13] wifi: cfg80211: reg: Support P2P operation on DFS channels

Miri Korenblit <[email protected]> writes:

> From: Andrei Otcheretianski <[email protected]>
>
> FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to
> operate on DFS channels while they operate under the control of a
> concurrent DFS master. For example, it is possible to have a P2P GO on a
> DFS channel as long as BSS connection is active on the same channel.
> Allow such operation by adding additional regulatory flags to indicate
> DFS concurrent channels and capable devices. Add the required
> relaxations in DFS regulatory checks.
>
> Signed-off-by: Andrei Otcheretianski <[email protected]>
> Reviewed-by: Gregory Greenman <[email protected]>
> Signed-off-by: Miri Korenblit <[email protected]>
> ---
> v2: fix the wrong email addresses

Thanks, looks good.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

2023-12-21 19:17:07

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH v2 06/13] wifi: mac80211: rework RX timestamp flags

On Tue, 2023-12-19 at 15:16 -0800, Jeff Johnson wrote:
> On 12/19/2023 2:43 PM, Johannes Berg wrote:
> > On Tue, 2023-12-19 at 14:41 -0800, Jeff Johnson wrote:
> > > now the code can return a value that doesn't map to the true/false bool
> > > enums
> >
> > No, it cannot, at least not if 'bool' is implemented in a C99-compliant
> > way :) It's not actually an enum, it will return 0/1 in the machine
> > register even with this code.
>
> Today I learned something new. Guess I'm still carrying baggage from
> pre-C99.

Which is not necessarily bad - there are to this day compilers that
implement bool as if it was an enum, and then it can hold values other
than 0/1 ... but at least for kernel work we can assume bool is
implemented as specified :)

johannes

2023-12-22 11:01:55

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

Miri Korenblit <[email protected]> writes:

> From: Mukesh Sisodiya <[email protected]>
>
> UHB AP send supported power type(LPI, SP, VLP)
> in beacon and probe response IE and STA should
> connect to these AP only if their regulatory support
> the AP power type.
>
> Beacon/Probe response are reported to userspace
> with reason "STA regulatory not supporting to connect to AP
> based on transmitted power type" and it should
> not connect to AP.
>
> Signed-off-by: Mukesh Sisodiya <[email protected]>
> Reviewed-by: Gregory Greenman <[email protected]>
> Signed-off-by: Miri Korenblit <[email protected]>

What's an UHB AP? Never heard of that before.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

2023-12-23 19:53:02

by Miri Korenblit

[permalink] [raw]
Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

> -----Original Message-----
> From: Kalle Valo <[email protected]>
> Sent: Friday, December 22, 2023 13:02
> To: Korenblit, Miriam Rachel <[email protected]>
> Cc: [email protected]; [email protected]; Sisodiya,
> Mukesh <[email protected]>; Greenman, Gregory
> <[email protected]>
> Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power
> type
>
> Miri Korenblit <[email protected]> writes:
>
> > From: Mukesh Sisodiya <[email protected]>
> >
> > UHB AP send supported power type(LPI, SP, VLP) in beacon and probe
> > response IE and STA should connect to these AP only if their
> > regulatory support the AP power type.
> >
> > Beacon/Probe response are reported to userspace with reason "STA
> > regulatory not supporting to connect to AP based on transmitted power
> > type" and it should not connect to AP.
> >
> > Signed-off-by: Mukesh Sisodiya <[email protected]>
> > Reviewed-by: Gregory Greenman <[email protected]>
> > Signed-off-by: Miri Korenblit <[email protected]>
>
> What's an UHB AP? Never heard of that before.

Ultra High Band (6 GHz) Aps

>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatch
> es


2023-12-29 13:51:28

by Sisodiya, Mukesh

[permalink] [raw]
Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

Hi Miri/ Kalle,
Yes, it is Ultra High band(6Ghz) AP.
Regards,
Mukesh Sisodiya
-----Original Message-----
From: Korenblit, Miriam Rachel <[email protected]>
Sent: Sunday, December 24, 2023 1:23 AM
To: Kalle Valo <[email protected]>
Cc: [email protected]; [email protected]; Sisodiya, Mukesh <[email protected]>; Greenman, Gregory <[email protected]>
Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

> -----Original Message-----
> From: Kalle Valo <[email protected]>
> Sent: Friday, December 22, 2023 13:02
> To: Korenblit, Miriam Rachel <[email protected]>
> Cc: [email protected]; [email protected];
> Sisodiya, Mukesh <[email protected]>; Greenman, Gregory
> <[email protected]>
> Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA
> power type
>
> Miri Korenblit <[email protected]> writes:
>
> > From: Mukesh Sisodiya <[email protected]>
> >
> > UHB AP send supported power type(LPI, SP, VLP) in beacon and probe
> > response IE and STA should connect to these AP only if their
> > regulatory support the AP power type.
> >
> > Beacon/Probe response are reported to userspace with reason "STA
> > regulatory not supporting to connect to AP based on transmitted
> > power type" and it should not connect to AP.
> >
> > Signed-off-by: Mukesh Sisodiya <[email protected]>
> > Reviewed-by: Gregory Greenman <[email protected]>
> > Signed-off-by: Miri Korenblit <[email protected]>
>
> What's an UHB AP? Never heard of that before.

Ultra High Band (6 GHz) Aps

>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittin
> gpatch
> es


2024-01-02 00:15:58

by Arend van Spriel

[permalink] [raw]
Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

On 12/29/2023 2:51 PM, Sisodiya, Mukesh wrote:
> Hi Miri/ Kalle,
> Yes, it is Ultra High band(6Ghz) AP.
> Regards,
> Mukesh Sisodiya
> -----Original Message-----
> From: Korenblit, Miriam Rachel <[email protected]>
> Sent: Sunday, December 24, 2023 1:23 AM
> To: Kalle Valo <[email protected]>
> Cc: [email protected]; [email protected]; Sisodiya, Mukesh <[email protected]>; Greenman, Gregory <[email protected]>
> Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type
>
>> -----Original Message-----
>> From: Kalle Valo <[email protected]>
>> Sent: Friday, December 22, 2023 13:02
>> To: Korenblit, Miriam Rachel <[email protected]>
>> Cc: [email protected]; [email protected];
>> Sisodiya, Mukesh <[email protected]>; Greenman, Gregory
>> <[email protected]>
>> Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA
>> power type
>>
>> Miri Korenblit <[email protected]> writes:
>>
>>> From: Mukesh Sisodiya <[email protected]>
>>>
>>> UHB AP send supported power type(LPI, SP, VLP) in beacon and probe
>>> response IE and STA should connect to these AP only if their
>>> regulatory support the AP power type.
>>>
>>> Beacon/Probe response are reported to userspace with reason "STA
>>> regulatory not supporting to connect to AP based on transmitted
>>> power type" and it should not connect to AP.
>>>
>>> Signed-off-by: Mukesh Sisodiya <[email protected]>
>>> Reviewed-by: Gregory Greenman <[email protected]>
>>> Signed-off-by: Miri Korenblit <[email protected]>
>>
>> What's an UHB AP? Never heard of that before.
>
> Ultra High Band (6 GHz) Aps

Not sure where the term is coming from. It is not in the 802.11
standards nor WFA specifications afaict.

Regards,
Arend

>>
>> --
>> https://patchwork.kernel.org/project/linux-wireless/list/
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittin
>> gpatch
>> es
>
>


Attachments:
smime.p7s (4.12 kB)
S/MIME Cryptographic Signature

2024-01-02 21:16:02

by Jeff Johnson

[permalink] [raw]
Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

On 1/1/2024 4:15 PM, Arend van Spriel wrote:
> On 12/29/2023 2:51 PM, Sisodiya, Mukesh wrote:
>> Hi Miri/ Kalle,
>> Yes, it is Ultra High band(6Ghz) AP.
>> Regards,
>> Mukesh Sisodiya
>> -----Original Message-----
>> From: Korenblit, Miriam Rachel <[email protected]>
>> Sent: Sunday, December 24, 2023 1:23 AM
>> To: Kalle Valo <[email protected]>
>> Cc: [email protected]; [email protected]; Sisodiya, Mukesh <[email protected]>; Greenman, Gregory <[email protected]>
>> Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type
>>
>>> -----Original Message-----
>>> From: Kalle Valo <[email protected]>
>>> Sent: Friday, December 22, 2023 13:02
>>> To: Korenblit, Miriam Rachel <[email protected]>
>>> Cc: [email protected]; [email protected];
>>> Sisodiya, Mukesh <[email protected]>; Greenman, Gregory
>>> <[email protected]>
>>> Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA
>>> power type
>>>
>>> Miri Korenblit <[email protected]> writes:
>>>
>>>> From: Mukesh Sisodiya <[email protected]>
>>>>
>>>> UHB AP send supported power type(LPI, SP, VLP) in beacon and probe
>>>> response IE and STA should connect to these AP only if their
>>>> regulatory support the AP power type.
>>>>
>>>> Beacon/Probe response are reported to userspace with reason "STA
>>>> regulatory not supporting to connect to AP based on transmitted
>>>> power type" and it should not connect to AP.
>>>>
>>>> Signed-off-by: Mukesh Sisodiya <[email protected]>
>>>> Reviewed-by: Gregory Greenman <[email protected]>
>>>> Signed-off-by: Miri Korenblit <[email protected]>
>>>
>>> What's an UHB AP? Never heard of that before.
>>
>> Ultra High Band (6 GHz) Aps
>
> Not sure where the term is coming from. It is not in the 802.11
> standards nor WFA specifications afaict.

I have the same concern. We should not introduce "marketing"
terminology; please stick to terminology used in the specifications.



2024-01-08 13:36:15

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type

Jeff Johnson <[email protected]> writes:

>>>> What's an UHB AP? Never heard of that before.
>>>
>>> Ultra High Band (6 GHz) Aps
>>
>> Not sure where the term is coming from. It is not in the 802.11
>> standards nor WFA specifications afaict.
>
> I have the same concern. We should not introduce "marketing"
> terminology; please stick to terminology used in the specifications.

Agreed. The commit logs should be understandable by any Linux engineer,
not just by wireless engineers.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

2024-02-29 21:41:27

by Ben Greear

[permalink] [raw]
Subject: Re: [PATCH v2 11/13] wifi: mac80211: fix advertised TTLM scheduling

On 12/20/23 03:41, Miri Korenblit wrote:
> From: Ayala Beker <[email protected]>
>
> Handle a case of time overflow, where the switch time might
> be smaller than the partial TSF in the beacon.
> Additionally, apply advertised TTLM earlier in order to be
> ready on time on the newly activated links.
>
> Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping")
> Signed-off-by: Ayala Beker <[email protected]>
> Reviewed-by: Johannes Berg <[email protected]>
> Signed-off-by: Miri Korenblit <[email protected]>

While rebasing my 6.7 tree on 6.8, I notice this patch applied, which I think means
it was not applied to 6.8 upstream. Was that on purpose?

Thanks,
Ben

> ---
> v2: Fix wrong email addresses
> ---
> net/mac80211/mlme.c | 49 ++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 40 insertions(+), 9 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index fe0be3e5731b..b526ce589d4d 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -43,6 +43,9 @@
> #define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
> #define IEEE80211_ASSOC_MAX_TRIES 3
>
> +#define IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS msecs_to_jiffies(100)
> +#define IEEE80211_ADV_TTLM_ST_UNDERFLOW 0xff00
> +
> static int max_nullfunc_tries = 2;
> module_param(max_nullfunc_tries, int, 0644);
> MODULE_PARM_DESC(max_nullfunc_tries,
> @@ -5965,6 +5968,13 @@ ieee80211_parse_adv_t2l(struct ieee80211_sub_if_data *sdata,
> pos++;
>
> ttlm_info->switch_time = get_unaligned_le16(pos);
> +
> + /* Since ttlm_info->switch_time == 0 means no switch time, bump it
> + * by 1.
> + */
> + if (!ttlm_info->switch_time)
> + ttlm_info->switch_time = 1;
> +
> pos += 2;
>
> if (control & IEEE80211_TTLM_CONTROL_EXPECTED_DUR_PRESENT) {
> @@ -6059,25 +6069,46 @@ static void ieee80211_process_adv_ttlm(struct ieee80211_sub_if_data *sdata,
> }
>
> if (ttlm_info.switch_time) {
> - u32 st_us, delay = 0;
> - u32 ts_l26 = beacon_ts & GENMASK(25, 0);
> + u16 beacon_ts_tu, st_tu, delay;
> + u32 delay_jiffies;
> + u64 mask;
>
> /* The t2l map switch time is indicated with a partial
> - * TSF value, convert it to TSF and calc the delay
> - * to the start time.
> + * TSF value (bits 10 to 25), get the partial beacon TS
> + * as well, and calc the delay to the start time.
> + */
> + mask = GENMASK_ULL(25, 10);
> + beacon_ts_tu = (beacon_ts & mask) >> 10;
> + st_tu = ttlm_info.switch_time;
> + delay = st_tu - beacon_ts_tu;
> +
> + /*
> + * If the switch time is far in the future, then it
> + * could also be the previous switch still being
> + * announced.
> + * We can simply ignore it for now, if it is a future
> + * switch the AP will continue to announce it anyway.
> + */
> + if (delay > IEEE80211_ADV_TTLM_ST_UNDERFLOW)
> + return;
> +
> + delay_jiffies = TU_TO_JIFFIES(delay);
> +
> + /* Link switching can take time, so schedule it
> + * 100ms before to be ready on time
> */
> - st_us = ieee80211_tu_to_usec(ttlm_info.switch_time);
> - if (st_us > ts_l26)
> - delay = st_us - ts_l26;
> + if (delay_jiffies > IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS)
> + delay_jiffies -=
> + IEEE80211_ADV_TTLM_SAFETY_BUFFER_MS;
> else
> - continue;
> + delay_jiffies = 0;
>
> sdata->u.mgd.ttlm_info = ttlm_info;
> wiphy_delayed_work_cancel(sdata->local->hw.wiphy,
> &sdata->u.mgd.ttlm_work);
> wiphy_delayed_work_queue(sdata->local->hw.wiphy,
> &sdata->u.mgd.ttlm_work,
> - usecs_to_jiffies(delay));
> + delay_jiffies);
> return;
> }
> }

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com



2024-02-29 22:47:33

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH v2 11/13] wifi: mac80211: fix advertised TTLM scheduling

On Thu, 2024-02-29 at 13:41 -0800, Ben Greear wrote:
> On 12/20/23 03:41, Miri Korenblit wrote:
> > From: Ayala Beker <[email protected]>
> >
> > Handle a case of time overflow, where the switch time might
> > be smaller than the partial TSF in the beacon.
> > Additionally, apply advertised TTLM earlier in order to be
> > ready on time on the newly activated links.
> >
> > Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping")
> > Signed-off-by: Ayala Beker <[email protected]>
> > Reviewed-by: Johannes Berg <[email protected]>
> > Signed-off-by: Miri Korenblit <[email protected]>
>
> While rebasing my 6.7 tree on 6.8, I notice this patch applied, which I think means
> it was not applied to 6.8 upstream. Was that on purpose?
>

It's there as far as I can tell?


commit b1a23f8ae0d76ad32fe36682730c050251275b0b
Author: Ayala Beker <[email protected]>
Date: Wed Dec 20 13:41:44 2023 +0200

wifi: mac80211: fix advertised TTLM scheduling


Maybe git rebase reduced yours to some whitespace changes or something
:)

johannes

2024-02-29 22:53:58

by Ben Greear

[permalink] [raw]
Subject: Re: [PATCH v2 11/13] wifi: mac80211: fix advertised TTLM scheduling

On 2/29/24 14:47, Johannes Berg wrote:
> On Thu, 2024-02-29 at 13:41 -0800, Ben Greear wrote:
>> On 12/20/23 03:41, Miri Korenblit wrote:
>>> From: Ayala Beker <[email protected]>
>>>
>>> Handle a case of time overflow, where the switch time might
>>> be smaller than the partial TSF in the beacon.
>>> Additionally, apply advertised TTLM earlier in order to be
>>> ready on time on the newly activated links.
>>>
>>> Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping")
>>> Signed-off-by: Ayala Beker <[email protected]>
>>> Reviewed-by: Johannes Berg <[email protected]>
>>> Signed-off-by: Miri Korenblit <[email protected]>
>>
>> While rebasing my 6.7 tree on 6.8, I notice this patch applied, which I think means
>> it was not applied to 6.8 upstream. Was that on purpose?
>>
>
> It's there as far as I can tell?

Yes, sorry about that. I even did a grep but my eyes saw only what they
expected to see. I just ended up with it double-applied, and will fix
that in my tree.

Thanks,
Ben

>
>
> commit b1a23f8ae0d76ad32fe36682730c050251275b0b
> Author: Ayala Beker <[email protected]>
> Date: Wed Dec 20 13:41:44 2023 +0200
>
> wifi: mac80211: fix advertised TTLM scheduling
>
>
> Maybe git rebase reduced yours to some whitespace changes or something
> :)
>
> johannes
>

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com