[PATCH v2 1/4] nl80211: advertise RU puncturing support to userspace

[PATCH v2 1/4] nl80211: advertise RU puncturing support to userspace

[Aloka Dixit]

RU preamble puncturing is allowed for bandwidths more that 80 MHz
except 80+80. Drivers may not support puncturing at all or have
restrictions for a minimum bandwidth.
Add new attribute NL80211_ATTR_RU_PUNCT_SUPP_BW to advertise the
driver support to the userspace. Default value (0) will indicate that
RU puncturing is not supported.

Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
---
v2: Moved boundary check for ru_punct_supp_bw to wiphy_register().

 include/net/cfg80211.h       |  6 ++++++
 include/uapi/linux/nl80211.h | 22 ++++++++++++++++++++++
 net/wireless/core.c          |  4 ++++
 net/wireless/nl80211.c       | 19 +++++++++++++++++++
 4 files changed, 51 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 68713388b617..46630a125e8e 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5129,6 +5129,10 @@ struct wiphy_iftype_akm_suites {
  * @ema_max_profile_periodicity: maximum profile periodicity supported by
  *	the driver. Setting this field to a non-zero value indicates that the
  *	driver supports enhanced multi-BSSID advertisements (EMA AP).
+ *
+ * @ru_punct_supp_bw: Whether the driver supports RU puncturing, and if so,
+ *	for which bandwidths. See &enum nl80211_ru_punct_supp_bw for the
+ *	possible values for this field.
  */
 struct wiphy {
 	struct mutex mtx;
@@ -5276,6 +5280,8 @@ struct wiphy {
 	u8 mbssid_max_interfaces;
 	u8 ema_max_profile_periodicity;
 
+	enum nl80211_ru_punct_supp_bw ru_punct_supp_bw;
+
 	char priv[] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 0568a79097b8..bdd2cb22b5a0 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2663,6 +2663,10 @@ enum nl80211_commands {
  *	association request when used with NL80211_CMD_NEW_STATION). Can be set
  *	only if %NL80211_STA_FLAG_WME is set.
  *
+ * @NL80211_ATTR_RU_PUNCT_SUPP_BW: (u8) Minimum bandwidth for which
+ *	the driver supports preamble puncturing, value should be of type
+ *	&enum nl80211_ru_punct_supp_bw
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3175,6 +3179,8 @@ enum nl80211_attrs {
 
 	NL80211_ATTR_EHT_CAPABILITY,
 
+	NL80211_ATTR_RU_PUNCT_SUPP_BW,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
@@ -7600,4 +7606,20 @@ enum nl80211_ap_settings_flags {
 	NL80211_AP_SETTINGS_SA_QUERY_OFFLOAD_SUPPORT	= 1 << 1,
 };
 
+/**
+ * enum nl80211_ru_punct_supp_bw - Bandwidths supporting preamble puncturing
+ *
+ * @NL80211_RU_PUNCT_NOT_SUPP: preamble puncturing is not supported
+ * @NL80211_RU_PUNCT_SUPP_BW_80: puncturing supported within channels of at
+ *	least 80 MHz bandwidth
+ * @NL80211_RU_PUNCT_SUPP_BW_160: puncturing supported within channels of at
+ *	least 160 MHz bandwidth
+ * @NL80211_RU_PUNCT_SUPP_BW_320: puncturing supported within 320 MHz.
+ */
+enum nl80211_ru_punct_supp_bw {
+	NL80211_RU_PUNCT_NOT_SUPP,
+	NL80211_RU_PUNCT_SUPP_BW_80,
+	NL80211_RU_PUNCT_SUPP_BW_160,
+	NL80211_RU_PUNCT_SUPP_BW_320,
+};
 #endif /* __LINUX_NL80211_H */
diff --git a/net/wireless/core.c b/net/wireless/core.c
index f08d4b3bb148..795f2400373d 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -892,6 +892,10 @@ int wiphy_register(struct wiphy *wiphy)
 		return -EINVAL;
 	}
 
+	if (WARN_ON(rdev->wiphy.ru_punct_supp_bw >
+		    NL80211_RU_PUNCT_SUPP_BW_320))
+		return -EINVAL;
+
 	for (i = 0; i < rdev->wiphy.n_vendor_commands; i++) {
 		/*
 		 * Validate we have a policy (can be explicitly set to
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ee1c2b6b6971..1fbfda2b3b14 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -790,6 +790,8 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
 		NLA_POLICY_RANGE(NLA_BINARY,
 				 NL80211_EHT_MIN_CAPABILITY_LEN,
 				 NL80211_EHT_MAX_CAPABILITY_LEN),
+	[NL80211_ATTR_RU_PUNCT_SUPP_BW] =
+		NLA_POLICY_MAX(NLA_U8, NL80211_RU_PUNCT_SUPP_BW_320),
 };
 
 /* policy for the key attributes */
@@ -2301,6 +2303,20 @@ static int nl80211_put_mbssid_support(struct wiphy *wiphy, struct sk_buff *msg)
 	return -ENOBUFS;
 }
 
+static int
+nl80211_put_ru_punct_supp_bw(struct cfg80211_registered_device *rdev,
+			     struct sk_buff *msg)
+{
+	if (!rdev->wiphy.ru_punct_supp_bw)
+		return 0;
+
+	if (nla_put_u8(msg, NL80211_ATTR_RU_PUNCT_SUPP_BW,
+		       rdev->wiphy.ru_punct_supp_bw))
+		return -ENOBUFS;
+
+	return 0;
+}
+
 struct nl80211_dump_wiphy_state {
 	s64 filter_wiphy;
 	long start;
@@ -2889,6 +2905,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
 		if (nl80211_put_mbssid_support(&rdev->wiphy, msg))
 			goto nla_put_failure;
 
+		if (nl80211_put_ru_punct_supp_bw(rdev, msg))
+			goto nla_put_failure;
+
 		/* done */
 		state->split_start = 0;
 		break;

base-commit: f5ba9781dde28f87d1e6db580ab63b308b5b5e1b
-- 
2.31.1

[PATCH v2 2/4] cfg80211: validate RU puncturing bitmap

[Aloka Dixit]

RU puncturing bitmap consists of 16 bits, each bit corresponding to
a 20 MHz channel in the operating bandwidth. Lowest bit corresponds to
the lowest frequency. Bit set to 1 indicates that the channel is
punctured otherwise it is active.

Validate the bitmap against following rules:
- Primary 20 MHz channel cannot be punctured
- As per IEEE P802.11be/D1.3, December 2021, 36.3.12.11.3 Preamble
  puncturing for PPDUs in a non-OFDMA transmission
- As per IEEE P802.11be/D1.3, December 2021, 36.3.12.11.2 Preamble
  puncturing for PPDUs in an OFDMA transmission.

Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
---
v2: Exported the function cfg80211_ru_punct_bitmap_valid() as
suggested in v1.

 include/net/cfg80211.h |  12 ++++-
 net/wireless/chan.c    | 100 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 111 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 46630a125e8e..b0f7993778aa 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -742,6 +742,11 @@ struct key_params {
  *	chan will define the primary channel and all other
  *	parameters are ignored.
  * @freq1_offset: offset from @center_freq1, in KHz
+ * @ru_punct_bitmap: RU puncturing bitmap. Each bit represents a 20 MHz channel
+ *	with lowest bit corresponding to the smallest frequency. Bit set to 1
+ *	indicates that the channel is punctured, otherwise the channel is active
+ * @ru_punct_bitmap_supp_he: Indicates whether RU puncturing bitmap validation
+ *	should include OFDMA bitmaps.
  */
 struct cfg80211_chan_def {
 	struct ieee80211_channel *chan;
@@ -750,6 +755,8 @@ struct cfg80211_chan_def {
 	u32 center_freq2;
 	struct ieee80211_edmg edmg;
 	u16 freq1_offset;
+	u16 ru_punct_bitmap;
+	bool ru_punct_bitmap_supp_he;
 };
 
 /*
@@ -878,7 +885,10 @@ cfg80211_chandef_identical(const struct cfg80211_chan_def *chandef1,
 		chandef1->width == chandef2->width &&
 		chandef1->center_freq1 == chandef2->center_freq1 &&
 		chandef1->freq1_offset == chandef2->freq1_offset &&
-		chandef1->center_freq2 == chandef2->center_freq2);
+		chandef1->center_freq2 == chandef2->center_freq2 &&
+		chandef1->ru_punct_bitmap == chandef2->ru_punct_bitmap &&
+		chandef1->ru_punct_bitmap_supp_he ==
+					chandef2->ru_punct_bitmap_supp_he);
 }
 
 /**
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 8b7fb4a9e07b..aa17631da087 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -32,6 +32,7 @@ void cfg80211_chandef_create(struct cfg80211_chan_def *chandef,
 	chandef->center_freq2 = 0;
 	chandef->edmg.bw_config = 0;
 	chandef->edmg.channels = 0;
+	chandef->ru_punct_bitmap = 0;
 
 	switch (chan_type) {
 	case NL80211_CHAN_NO_HT:
@@ -196,6 +197,102 @@ static int cfg80211_chandef_get_width(const struct cfg80211_chan_def *c)
 	return nl80211_chan_width_to_mhz(c->width);
 }
 
+/* IEEE P802.11be/D1.31, December 2021, Table 36-30 5-bit punctured channel
+ * indication for the non-OFDMA case in an EHT MU PPDU
+ */
+static const u16 ru_punct_bitmap_80[] = {0xF, 0xE, 0xD, 0xB, 0x7};
+static const u16 ru_punct_bitmap_160[] = {0xFF, 0xFE, 0xFD, 0xFB, 0xF7, 0xEF,
+					  0xDF, 0xBF, 0x7F, 0xFC, 0xF3, 0xCF,
+					  0x3F};
+static const u16 ru_punct_bitmap_320[] = {0xFFFF, 0xFFFC, 0xFFF3, 0xFFCF,
+					  0xFF3F, 0xFCFF, 0xF3FF, 0xCFFF,
+					  0x3FFF, 0xFFF0, 0xFF0F, 0xF0FF,
+					  0x0FFF, 0xFFC0, 0xFF30, 0xFCF0,
+					  0xF3F0, 0xCFF0, 0x3FF0, 0x0FFC,
+					  0x0FF3, 0x0FCF, 0x0F3F, 0x0CFF,
+					  0x03FF};
+
+bool cfg80211_ru_punct_bitmap_valid(const struct cfg80211_chan_def *chandef)
+{
+	u8 i, non_ofdma_bitmap_count, ofdma_block_count = 1;
+	u16 bitmap, pri_ch_bit_pos;
+	const u16 *non_ofdma_bitmap;
+	u32 start_freq;
+
+	if (!chandef->ru_punct_bitmap) /* All channels active */
+		return true;
+
+	bitmap = ~chandef->ru_punct_bitmap;
+	WARN_ON_ONCE(sizeof(bitmap) != sizeof(chandef->ru_punct_bitmap));
+
+	switch (chandef->width) {
+	case NL80211_CHAN_WIDTH_80:
+		bitmap &= 0xF;
+		non_ofdma_bitmap = &ru_punct_bitmap_80[0];
+		non_ofdma_bitmap_count = ARRAY_SIZE(ru_punct_bitmap_80);
+		start_freq = chandef->center_freq1 - 40;
+		break;
+
+	case NL80211_CHAN_WIDTH_160:
+		bitmap &= 0xFF;
+		non_ofdma_bitmap = &ru_punct_bitmap_160[0];
+		non_ofdma_bitmap_count = ARRAY_SIZE(ru_punct_bitmap_160);
+		ofdma_block_count = 2;
+		start_freq = chandef->center_freq1 - 80;
+		break;
+
+	case NL80211_CHAN_WIDTH_320:
+		bitmap &= 0xFFFF;
+		non_ofdma_bitmap = &ru_punct_bitmap_320[0];
+		non_ofdma_bitmap_count = ARRAY_SIZE(ru_punct_bitmap_320);
+		ofdma_block_count = 4;
+		start_freq = chandef->center_freq1 - 160;
+		break;
+
+	default:
+		return false;
+	}
+
+	if (!bitmap) /* No channel active */
+		return false;
+
+	pri_ch_bit_pos = ((chandef->chan->center_freq - start_freq) / 20);
+	if (!(bitmap & BIT(pri_ch_bit_pos)))
+		return false;
+
+	/* Check for non-OFDMA puncturing patterns */
+	for (i = 0; i < non_ofdma_bitmap_count; i++)
+		if (non_ofdma_bitmap[i] == bitmap)
+			return true;
+
+	if (!chandef->ru_punct_bitmap_supp_he)
+		return false;
+
+	/* Check for OFDMA puncturing patterns */
+	for (i = 0; i < ofdma_block_count; i++) {
+		switch ((bitmap >> (i * 4)) & 0xF) {
+		/* IEEE P802.11be/D1.31, December 2021, 36.3.12.11.2 Preamble
+		 * puncturing for PPDUs in an OFDMA transmission
+		 */
+		case 0xF:
+		case 0x7:
+		case 0xB:
+		case 0xD:
+		case 0xE:
+		case 0x3:
+		case 0xC:
+		case 0x9:
+		case 0x0:
+			break;
+		default:
+			return false;
+		}
+	}
+
+	return true;
+}
+EXPORT_SYMBOL(cfg80211_ru_punct_bitmap_valid);
+
 bool cfg80211_chandef_valid(const struct cfg80211_chan_def *chandef)
 {
 	u32 control_freq, oper_freq;
@@ -316,6 +413,9 @@ bool cfg80211_chandef_valid(const struct cfg80211_chan_def *chandef)
 	    !cfg80211_edmg_chandef_valid(chandef))
 		return false;
 
+	if (!cfg80211_ru_punct_bitmap_valid(chandef))
+		return false;
+
 	return true;
 }
 EXPORT_SYMBOL(cfg80211_chandef_valid);
-- 
2.31.1

Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap

[Johannes Berg]

> + * @ru_punct_bitmap: RU puncturing bitmap. Each bit represents a 20 MHz channel
> + *	with lowest bit corresponding to the smallest frequency. Bit set to 1
> + *	indicates that the channel is punctured, otherwise the channel is active
> + * @ru_punct_bitmap_supp_he: Indicates whether RU puncturing bitmap validation
> + *	should include OFDMA bitmaps.
>   */
>  struct cfg80211_chan_def {
>  	struct ieee80211_channel *chan;
> @@ -750,6 +755,8 @@ struct cfg80211_chan_def {
>  	u32 center_freq2;
>  	struct ieee80211_edmg edmg;
>  	u16 freq1_offset;
> +	u16 ru_punct_bitmap;
> +	bool ru_punct_bitmap_supp_he;

I don't feel we finished the discussion on why it should be in the
chandef.

On the one hand, I can see how you argue that it's a part of how the
channel is defined, after all, this is now in a sense different from the
non- or differently-punctured channel since some parts of it are "gone".

This makes saying that two chandefs are only identical if also their
puncturing matches completely sensible, as seen in the changed
implementation of cfg80211_chandef_identical().


On the other hand, however, I don't think this makes a lot of sense with
mac80211's channel contexts, and especially not in a client-side
implementation. If you were to e.g. have two simultaneous connections to
two different APs on the "same" channel but different puncturing
configuration, I'm not convinced it makes sense to treat that as
requiring two entirely separate channel contexts and have to go to
powersave on one AP to receive on the other etc.? At least from my
(Intel HW) POV that doesn't make much sense.

As a result, we treat the puncturing more of a bss_conf type thing, and
we indeed have a patch to do that for the client side, which I should
get sent out so we can have a better discussion about both sides.


But honestly part of that probably is that I don't really entirely
understand the need for puncturing in the first place.


(and also, you included all kinds of random other things in these
patches, specifically in nl80211.h, so there's no way I can apply them
as is anyway)

johannes

Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap

[Aloka Dixit]

On 3/24/2022 3:37 AM, Johannes Berg wrote:
> 
> (and also, you included all kinds of random other things in these
> patches, specifically in nl80211.h, so there's no way I can apply them
> as is anyway)
> 

I had added the other nl80211 parts to match local user-space
nl80211 order during testing, forgot to take it out.

Let's discuss once your client side version is sent out.

Thanks.

Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap

[Balamurugan Mahalingam]

>
>
>
> -------- Forwarded Message --------
> Subject: Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap
> Date: Thu, 24 Mar 2022 09:35:27 -0700
> From: Aloka Dixit <quic_alokad@quicinc.com>
> To: Johannes Berg <johannes@sipsolutions.net>, 
> linux-wireless@vger.kernel.org
>
> On 3/24/2022 3:37 AM, Johannes Berg wrote:
>>
>> (and also, you included all kinds of random other things in these
>> patches, specifically in nl80211.h, so there's no way I can apply them
>> as is anyway)
>>
>
> I had added the other nl80211 parts to match local user-space
> nl80211 order during testing, forgot to take it out.
>
> Let's discuss once your client side version is sent out.
>
> Thanks.


9.4.2.45 Multiple BSSID element (excerpts from Draft 2.0 version)
The Timestamp and Beacon Interval fields, TIM, DSSS Parameter Set, IBSS 
Parameter Set, Coun
try, Channel Switch Announcement, Extended Channel Switch Announcement, 
Wide Bandwidth Channel Switch, Transmit Power Envelope, Supported 
Operating Classes, IBSS DFS, ERP Informa
tion, HT Capabilities, HT Operation, VHT Capabilities, and VHT 
Operation, S1G Beacon Compati
bility, Short Beacon Interval, S1G Capabilities, and S1G Operation, HE 
Capabilities, HE 6 GHz Band Capabilities, HE Operation, BSS Color Change 
Announcement,
and Spatial Reuse Parameter Set , EHT Capabilities, and EHT Operation
elements are not included in the Nontransmitted BSSID Profile 
subelement; the values of these elements for each nontransmitted BSSID 
are always the same as the corresponding transmitted BSSID element values.




Hi Johannes,


I am looking at the change in design and i see the below concerns.

While a BSS level RU puncturing gives the flexibility of configuring 
different puncturing bitmaps in MBSSID scenario, the same cannot be 
advertised on a per BSS basis over the beacon to the stations trying to 
associate with the AP. (with reference to text above from Spec)

1. There is a only one EHT operation element (which holds the disabled 
subchannel bitmap) that can be announced in a MBSSID beacon.
     The spec doesn't allow to announce EHT operation on a per BSS basis.
2. Having a ru_puncturing_bitmap at the chandef level for the AP mode 
could also help us decide easily whether DFS is needed or not (Skip DFS 
if the dfs channels are punctured) .  Having RU puncturing at BSS level 
could again lead to confusion if certain BSSes of a single phy are 
configured with different RU puncturing bitmaps some including the DFS 
channel and some puncturing out all the  DFS channels.

Shall we retain the RU puncturing bitmap at chandef level for the AP 
mode and keep the RU puncturing bitmap at BSS level for the STA scenarios?


From: Johannes

that's probably a discussion better had on the mailing list, rather than 
long-form chat here? :)

not sure it's easy to do with AP/client modes different since we also 
have AP + client concurrency scenarios


Hi Johannes,

I have captured the offline discussions above to set the context for others.

Even in the AP & STA concurrent scenario, i believe this approach should 
work.
     1. In the STA case, The STA shall use the puncture pattern from its 
BSS conf for all transmission to its connected AP.
     2. In the AP case ( MBSSID case as well), the AP  shall use the 
puncture pattern from the chandef while it transmits frame to its 
connected stations.
         The chandef ru_punct_bitmap ultimately gets assigned to the 
virtual interfaces at the driver when virtual interfaces are created.
         The AP vif shall use the value to control the transmissions to 
all its connected stations.
         Since the ru_punct_bitmap is announced over EHT Operation IE, 
the connected stations would limit its transmission only to the 
non-punctured channels.


Could you please share your comments on the above approach?


Thanks

Maha

[PATCH v2 3/4] nl80211: validate RU puncturing bitmap

[Aloka Dixit]

Add new attributes NL80211_ATTR_RU_PUNCT_BITMAP and
NL80211_ATTR_RU_PUNCT_SUPP_HE to receive RU puncturing information
from the userspace.
- Bitmap consists of 16 bits, each bit corresponding to a 20 MHz
channel in the operating bandwidth. Lowest bit corresponds to
the lowest frequency. Validate the bitmap against the minimum
bandwidth support advertised by the driver.
- HE support flag indicates whether OFDMA puncturing patterns
should be considered during validation.

Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
---
 include/uapi/linux/nl80211.h | 20 +++++++++++++++
 net/wireless/nl80211.c       | 49 ++++++++++++++++++++++++++++++++++++
 2 files changed, 69 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index bdd2cb22b5a0..e8b9f07cdd38 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1469,6 +1469,8 @@ enum nl80211_commands {
 
 	NL80211_CMD_SET_SAR_SPECS,
 
+	NL80211_CMD_UPDATE_HE_MUEDCA_PARAMS,
+
 	NL80211_CMD_OBSS_COLOR_COLLISION,
 
 	NL80211_CMD_COLOR_CHANGE_REQUEST,
@@ -1477,6 +1479,8 @@ enum nl80211_commands {
 	NL80211_CMD_COLOR_CHANGE_ABORTED,
 	NL80211_CMD_COLOR_CHANGE_COMPLETED,
 
+	NL80211_CMD_AWGN_DETECT,
+
 	NL80211_CMD_SET_FILS_AAD,
 
 	NL80211_CMD_ASSOC_COMEBACK,
@@ -2667,6 +2671,14 @@ enum nl80211_commands {
  *	the driver supports preamble puncturing, value should be of type
  *	&enum nl80211_ru_punct_supp_bw
  *
+ * @NL80211_ATTR_RU_PUNCT_SUPP_HE: flag attribute, used to indicate that RU
+ *	puncturing bitmap validation should include OFDMA bitmaps.
+ *
+ * @NL80211_ATTR_RU_PUNCT_BITMAP: (u16) RU puncturing bitmap where the lowest
+ *	bit corresponds to the lowest 20 MHz channel. Each bit set to 1
+ *	indicates that the sub-channel is punctured, set 0 indicates that the
+ *	channel is active.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3164,6 +3176,8 @@ enum nl80211_attrs {
 
 	NL80211_ATTR_DISABLE_HE,
 
+	NL80211_ATTR_HE_MUEDCA_PARAMS,
+
 	NL80211_ATTR_OBSS_COLOR_BITMAP,
 
 	NL80211_ATTR_COLOR_CHANGE_COUNT,
@@ -3180,6 +3194,8 @@ enum nl80211_attrs {
 	NL80211_ATTR_EHT_CAPABILITY,
 
 	NL80211_ATTR_RU_PUNCT_SUPP_BW,
+	NL80211_ATTR_RU_PUNCT_SUPP_HE,
+	NL80211_ATTR_RU_PUNCT_BITMAP,
 
 	/* add attributes here, update the policy in nl80211.c */
 
@@ -4170,6 +4186,10 @@ enum nl80211_reg_rule_attr {
 
 	NL80211_ATTR_DFS_CAC_TIME,
 
+	NL80211_ATTR_POWER_RULE_PSD,
+
+	NL80211_ATTR_REG_POWER_MODE,
+
 	/* keep last */
 	__NL80211_REG_RULE_ATTR_AFTER_LAST,
 	NL80211_REG_RULE_ATTR_MAX = __NL80211_REG_RULE_ATTR_AFTER_LAST - 1
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1fbfda2b3b14..e3a7a94d89ca 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -792,6 +792,8 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
 				 NL80211_EHT_MAX_CAPABILITY_LEN),
 	[NL80211_ATTR_RU_PUNCT_SUPP_BW] =
 		NLA_POLICY_MAX(NLA_U8, NL80211_RU_PUNCT_SUPP_BW_320),
+	[NL80211_ATTR_RU_PUNCT_SUPP_HE] = { .type = NLA_FLAG },
+	[NL80211_ATTR_RU_PUNCT_BITMAP] = { .type = NLA_U16 },
 };
 
 /* policy for the key attributes */
@@ -3122,6 +3124,46 @@ static bool nl80211_can_set_dev_channel(struct wireless_dev *wdev)
 		wdev->iftype == NL80211_IFTYPE_P2P_GO;
 }
 
+static int nl80211_parse_ru_punct_bitmap(struct cfg80211_registered_device *rdev,
+					 struct genl_info *info,
+					 struct cfg80211_chan_def *chandef)
+{
+	chandef->ru_punct_bitmap_supp_he =
+		nla_get_flag(info->attrs[NL80211_ATTR_RU_PUNCT_SUPP_HE]);
+
+	chandef->ru_punct_bitmap =
+		nla_get_u16(info->attrs[NL80211_ATTR_RU_PUNCT_BITMAP]);
+
+	if (!chandef->ru_punct_bitmap)
+		return 0;
+
+	if (!rdev->wiphy.ru_punct_supp_bw &&
+	    (chandef->ru_punct_bitmap || chandef->ru_punct_bitmap_supp_he))
+		return -EOPNOTSUPP;
+
+	switch (chandef->width) {
+	case NL80211_CHAN_WIDTH_80:
+		if (rdev->wiphy.ru_punct_supp_bw >=
+		    NL80211_RU_PUNCT_SUPP_BW_160)
+			return -EOPNOTSUPP;
+		break;
+
+	case NL80211_CHAN_WIDTH_160:
+		if (rdev->wiphy.ru_punct_supp_bw >=
+		    NL80211_RU_PUNCT_SUPP_BW_320)
+			return -EOPNOTSUPP;
+		break;
+
+	case NL80211_CHAN_WIDTH_320:
+		break;
+
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+
 int nl80211_parse_chandef(struct cfg80211_registered_device *rdev,
 			  struct genl_info *info,
 			  struct cfg80211_chan_def *chandef)
@@ -3129,6 +3171,7 @@ int nl80211_parse_chandef(struct cfg80211_registered_device *rdev,
 	struct netlink_ext_ack *extack = info->extack;
 	struct nlattr **attrs = info->attrs;
 	u32 control_freq;
+	int err;
 
 	if (!attrs[NL80211_ATTR_WIPHY_FREQ])
 		return -EINVAL;
@@ -3205,6 +3248,12 @@ int nl80211_parse_chandef(struct cfg80211_registered_device *rdev,
 				nla_get_u32(attrs[NL80211_ATTR_CENTER_FREQ2]);
 	}
 
+	if (info->attrs[NL80211_ATTR_RU_PUNCT_BITMAP]) {
+		err = nl80211_parse_ru_punct_bitmap(rdev, info, chandef);
+		if (err)
+			return err;
+	}
+
 	if (info->attrs[NL80211_ATTR_WIPHY_EDMG_CHANNELS]) {
 		chandef->edmg.channels =
 		      nla_get_u8(info->attrs[NL80211_ATTR_WIPHY_EDMG_CHANNELS]);
-- 
2.31.1

[PATCH v2 4/4] mac80211: reset puncturing bitmap during width downgrade

[Aloka Dixit]

Set the RU puncturing bitmap to 0 if for any reason bandwidth
is downgraded to less than 80 Mhz.

Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
---
 net/mac80211/util.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 682a164f795a..0dd7e8dae5a9 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -4135,6 +4135,13 @@ u32 ieee80211_chandef_downgrade(struct cfg80211_chan_def *c)
 		break;
 	}
 
+	if (c->width != NL80211_CHAN_WIDTH_320 &&
+	    c->width != NL80211_CHAN_WIDTH_160 &&
+	    c->width != NL80211_CHAN_WIDTH_80) {
+		c->ru_punct_bitmap = 0;
+		c->ru_punct_bitmap_supp_he = 0;
+	}
+
 	WARN_ON_ONCE(!cfg80211_chandef_valid(c));
 
 	return ret;
-- 
2.31.1

Re: [PATCH v2 1/4] nl80211: advertise RU puncturing support to userspace

[Aloka Dixit]

On 3/23/2022 12:16 PM, Aloka Dixit wrote:
> RU preamble puncturing is allowed for bandwidths more that 80 MHz
> except 80+80. Drivers may not support puncturing at all or have
> restrictions for a minimum bandwidth.
> Add new attribute NL80211_ATTR_RU_PUNCT_SUPP_BW to advertise the
> driver support to the userspace. Default value (0) will indicate that
> RU puncturing is not supported.
> 
> Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
> ---
> v2: Moved boundary check for ru_punct_supp_bw to wiphy_register().
> 

These patches depend on EHT support from
https://patchwork.kernel.org/project/linux-wireless/list/?series=614176&state=%2A&archive=both 
which are not yet present in mac80211-next tree.
But found those in wireless-next tree hence I used the same repository.

Re: [PATCH v2 1/4] nl80211: advertise RU puncturing support to userspace

[Johannes Berg]

On Wed, 2022-03-23 at 13:45 -0700, Aloka Dixit wrote:
> On 3/23/2022 12:16 PM, Aloka Dixit wrote:
> > RU preamble puncturing is allowed for bandwidths more that 80 MHz
> > except 80+80. Drivers may not support puncturing at all or have
> > restrictions for a minimum bandwidth.
> > Add new attribute NL80211_ATTR_RU_PUNCT_SUPP_BW to advertise the
> > driver support to the userspace. Default value (0) will indicate that
> > RU puncturing is not supported.
> > 
> > Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
> > ---
> > v2: Moved boundary check for ru_punct_supp_bw to wiphy_register().
> > 
> 
> These patches depend on EHT support from
> https://patchwork.kernel.org/project/linux-wireless/list/?series=614176&state=%2A&archive=both 
> which are not yet present in mac80211-next tree.
> 

There's no mac80211-next tree anymore. Well, it exists, but we've moved
to a combined tree in wireless-next.

johannes