[PATCH wireless] wifi: mac80211: do not permit 40 MHz EHT operation on 5/6 GHz

[PATCH wireless] wifi: mac80211: do not permit 40 MHz EHT operation on 5/6 GHz

[Miri Korenblit]

From: Benjamin Berg <benjamin.berg@intel.com>

The EHT PHY requirements state that 80 MHz must be supported on the 5
and 6 GHz bands unless the STA is 20 MHz only. So if the channel width
is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and
downgrade to HE.

The primary case where this can happen is if the hardware disables
puncturing using IEEE80211_HW_DISALLOW_PUNCTURING.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
 net/mac80211/mlme.c            |  8 ++++++++
 net/mac80211/tests/chan-mode.c | 30 +++++++++++++++++++++++++-----
 2 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 1008eb8e9b13..dd650a127a31 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1189,6 +1189,14 @@ ieee80211_determine_chan_mode(struct ieee80211_sub_if_data *sdata,
 			     "required MCSes not supported, disabling EHT\n");
 	}
 
+	if (conn->mode >= IEEE80211_CONN_MODE_EHT &&
+	    channel->band != NL80211_BAND_2GHZ &&
+	    conn->bw_limit == IEEE80211_CONN_BW_LIMIT_40) {
+		conn->mode = IEEE80211_CONN_MODE_HE;
+		link_id_info(sdata, link_id,
+			     "required bandwidth not supported, disabling EHT\n");
+	}
+
 	/* the mode can only decrease, so this must terminate */
 	if (ap_mode != conn->mode) {
 		kfree(elems);
diff --git a/net/mac80211/tests/chan-mode.c b/net/mac80211/tests/chan-mode.c
index 96c7b3ab2744..adc069065e73 100644
--- a/net/mac80211/tests/chan-mode.c
+++ b/net/mac80211/tests/chan-mode.c
@@ -2,7 +2,7 @@
 /*
  * KUnit tests for channel mode functions
  *
- * Copyright (C) 2024 Intel Corporation
+ * Copyright (C) 2024-2025 Intel Corporation
  */
 #include <net/cfg80211.h>
 #include <kunit/test.h>
@@ -28,6 +28,10 @@ static const struct determine_chan_mode_case {
 	u8 vht_basic_mcs_1_4, vht_basic_mcs_5_8;
 	u8 he_basic_mcs_1_4, he_basic_mcs_5_8;
 	u8 eht_mcs7_min_nss;
+	u16 eht_disabled_subchannels;
+	u8 eht_bw;
+	enum ieee80211_conn_bw_limit conn_bw_limit;
+	enum ieee80211_conn_bw_limit expected_bw_limit;
 	int error;
 } determine_chan_mode_cases[] = {
 	{
@@ -128,6 +132,14 @@ static const struct determine_chan_mode_case {
 		.conn_mode = IEEE80211_CONN_MODE_EHT,
 		.eht_mcs7_min_nss = 0x15,
 		.error = EINVAL,
+	}, {
+		.desc = "80 MHz EHT is downgraded to 40 MHz HE due to puncturing",
+		.conn_mode = IEEE80211_CONN_MODE_EHT,
+		.expected_mode = IEEE80211_CONN_MODE_HE,
+		.conn_bw_limit = IEEE80211_CONN_BW_LIMIT_80,
+		.expected_bw_limit = IEEE80211_CONN_BW_LIMIT_40,
+		.eht_disabled_subchannels = 0x08,
+		.eht_bw = IEEE80211_EHT_OPER_CHAN_WIDTH_80MHZ,
 	}
 };
 KUNIT_ARRAY_PARAM_DESC(determine_chan_mode, determine_chan_mode_cases, desc)
@@ -138,7 +150,7 @@ static void test_determine_chan_mode(struct kunit *test)
 	struct t_sdata *t_sdata = T_SDATA(test);
 	struct ieee80211_conn_settings conn = {
 		.mode = params->conn_mode,
-		.bw_limit = IEEE80211_CONN_BW_LIMIT_20,
+		.bw_limit = params->conn_bw_limit,
 	};
 	struct cfg80211_bss cbss = {
 		.channel = &t_sdata->band_5ghz.channels[0],
@@ -191,14 +203,21 @@ static void test_determine_chan_mode(struct kunit *test)
 		0x7f, 0x01, 0x00, 0x88, 0x88, 0x88, 0x00, 0x00,
 		0x00,
 		/* EHT Operation */
-		WLAN_EID_EXTENSION, 0x09, WLAN_EID_EXT_EHT_OPERATION,
-		0x01, params->eht_mcs7_min_nss ? params->eht_mcs7_min_nss : 0x11,
-		0x00, 0x00, 0x00, 0x00, 0x24, 0x00,
+		WLAN_EID_EXTENSION, 0x0b, WLAN_EID_EXT_EHT_OPERATION,
+		0x03, params->eht_mcs7_min_nss ? params->eht_mcs7_min_nss : 0x11,
+		0x00, 0x00, 0x00, params->eht_bw,
+		params->eht_bw == IEEE80211_EHT_OPER_CHAN_WIDTH_80MHZ ? 42 : 36,
+		0x00,
+		u16_get_bits(params->eht_disabled_subchannels, 0xff),
+		u16_get_bits(params->eht_disabled_subchannels, 0xff00),
 	};
 	struct ieee80211_chan_req chanreq = {};
 	struct cfg80211_chan_def ap_chandef = {};
 	struct ieee802_11_elems *elems;
 
+	/* To force EHT downgrade to HE on punctured 80 MHz downgraded to 40 MHz */
+	set_bit(IEEE80211_HW_DISALLOW_PUNCTURING, t_sdata->local.hw.flags);
+
 	if (params->strict)
 		set_bit(IEEE80211_HW_STRICT, t_sdata->local.hw.flags);
 	else
@@ -237,6 +256,7 @@ static void test_determine_chan_mode(struct kunit *test)
 	} else {
 		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, elems);
 		KUNIT_ASSERT_EQ(test, conn.mode, params->expected_mode);
+		KUNIT_ASSERT_EQ(test, conn.bw_limit, params->expected_bw_limit);
 	}
 }
 
-- 
2.34.1

Re: [PATCH wireless] wifi: mac80211: do not permit 40 MHz EHT operation on 5/6 GHz

[Pablo MARTIN-GOMEZ]

Hi,

On 26/08/2025 19:26, Miri Korenblit wrote:
> From: Benjamin Berg <benjamin.berg@intel.com>
>
> The EHT PHY requirements state that 80 MHz must be supported on the 5
> and 6 GHz bands unless the STA is 20 MHz only. So if the channel width
> is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and
> downgrade to HE.

This is wrong one way or another.

If we follow the 802.11 standard strictly [I'm going to use annex B's 
items so it is easier to follow], we are implementing EHTP3.3, so a non 
20 MHz-Only STA has to support 80 MHz channel width, therefore a 40 MHz 
(max) STA would not be compliant and we have to downgrade it. The issue 
is that HEP3.3 also requires that a non 20 MHz-Only HE STA has to 
support 80 MHz channel width, therefore downgrading to HE is not ok. We 
have the same issue with VHTP3.3 that requires a VHT STA to support 80 
MHz channel width, therefore downgrading to VHT is not okay either. So 
that means that the strictly compliant approach would be to disallow a 
40 MHz STA in the 6 GHz band and downgrade a 40 MHz STA to HT in the 
5GHz band.

If we follow the 802.11 standard more liberally, we never enforced 
VHTP3.3 nor HEP3.3, so why begin now with EHTP3.3?

>
> The primary case where this can happen is if the hardware disables
> puncturing using IEEE80211_HW_DISALLOW_PUNCTURING.
>
> Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
> Cc: stable@vger.kernel.org
> Reviewed-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>

Best regards,

Pablo MG

Re: [PATCH wireless] wifi: mac80211: do not permit 40 MHz EHT operation on 5/6 GHz

[Johannes Berg]

On Tue, 2025-08-26 at 21:02 +0200, Pablo MARTIN-GOMEZ wrote:
> > The EHT PHY requirements state that 80 MHz must be supported on the 5
> > and 6 GHz bands unless the STA is 20 MHz only. So if the channel width
> > is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and
> > downgrade to HE.
> 
> This is wrong one way or another.
> 
> If we follow the 802.11 standard strictly [I'm going to use annex B's 
> items so it is easier to follow], we are implementing EHTP3.3, so a non 

I ... don't think that's a good (correct?) way to phrase it. "Implement
EHTP3.3" means you have 80 MHz support, which is required unless it's 20
MHz only STA. Here we're not really implementing 80 MHz support but
saying that this is a requirement ...

> 20 MHz-Only STA has to support 80 MHz channel width, therefore a 40 MHz 
> (max) STA would not be compliant and we have to downgrade it. The issue 
> is that HEP3.3 also requires that a non 20 MHz-Only HE STA has to 
> support 80 MHz channel width, therefore downgrading to HE is not ok.

Again this is misleading, HEP3.3 states no such thing, it just asks if
you have it. Clause 27 states though that 40 and 80 MHz bandwidths must
be supported (except for 20 MHz-only non-AP HE STA), so yes, you're
still right that our downgrade is wrong, but talking about conforma
items is confusing at best?

(FWIW, I've also never seen an actual statement from anyone, it really
doesn't seem to be relevant in practice at all.)

> We 
> have the same issue with VHTP3.3 that requires a VHT STA to support 80 
> MHz channel width, therefore downgrading to VHT is not okay either.

Similarly, Clause 21, not VHTP3.3, and in this case there's not even an
allowance for 20-MHz only STA. I guess VHTP3.3 is a mere formality then.

Anyway I know you meant this only as something to talk about, but I
still think it's confusing, you should state the normative text that
actually requires something, not the (normative) text about what the
manufacturer should state for a device that claims compatibility.


> So 
> that means that the strictly compliant approach would be to disallow a 
> 40 MHz STA in the 6 GHz band and downgrade a 40 MHz STA to HT in the 
> 5GHz band.

Looks like, yes. We should probably do that. These are corner cases
anyway though, I don't think I've ever actually seen it happen.

> If we follow the 802.11 standard more liberally, we never enforced 
> VHTP3.3 nor HEP3.3, so why begin now with EHTP3.3?

Nobody found bugs with the other ones? ;-)

Here it comes down to this actually _happening_ due some devices not
allowing puncturing, and then we can't connect in the right way.

And this doesn't matter to HE, if we connect to an AP with puncturing in
the 80 MHz as an 80 MHz HE station, then it _must_ have HE not punctured
so only 40 MHz. Then if the HE actually moves to 80 MHz the puncturing
in EHT must go away, and the HE is 80 MHz unpunctured which is fine for
the HE STA, so there isn't even a bug.

The only bug would be if the downgrade happens for reasons other than
puncturing (e.g. regulatory bands) but this is very unlikely in the
first place.

So practically, the only issue we had with this is that for EHT and
puncturing, and then the downgrade to HE basically fixes that issue and
we can connect with HE even if we pretend we can do 80 MHz because as
long as the puncturing is there, the AP has to use 20 or 40 MHz
operation for HE (and lower of course.)


I agree though that this isn't really completely correct for HE/VHT if
the downgrade were to happen for other reasons.

However, I also don't think this is an argument _against_ fixing this
issue for EHT. Clearly, for EHT there's the additional practical
puncturing issue that matters. Yes, the APs rate scaling might be able
to cope with it eventually, but if we remain connected with EHT and
pretend we're 80 MHz when we're not, then we could get RUs in the
unavailable part etc. and I think rate scaling would probably not deal
with that well. This is true for HE as well, of course, but see above?

johannes