[PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band

[PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band

[Nicolas Escande]

The spec (at least 802.11-be draft7) at section 9.4.2.323.3 says we should
not set the 320MHz related fields when not operating on a 6GHz band. It's
quite explicit for most of them. For example:

Bit 0 "Support For 320 MHz In 6 GHz" says "Reserved if the EHT
      Capabilities element is indicating capabilities for the 2.4 GHz or
      5 GHz bands."

Bit 22-24 "Number Of Sounding Dimensions (= 320 MHz)" says "Reserved if
          the SU Beamformer subfield is 0 or the Support For 320 MHz In
          6 GHz subfield in EHT Capabilities Information field does not
          indicate support for a bandwidth of 320 MHz."

Bit 54 "Support Of EHT-MCS 15 In MRU" says about bit 3 "If 320 MHz is not
        supported, then B3 is set to 0."

For bit 13-15 "Beamformee SS (= 320 MHz)" it's not explicit, but it makes
little sense to special case the handling of this one.

Fixes: 6239da18d2f9 ("wifi: mac80211: adjust EHT capa when lowering bandwidth")
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
 net/mac80211/util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 0c46009a3d63..996983f6815b 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -4426,7 +4426,8 @@ int ieee80211_put_eht_cap(struct sk_buff *skb,
 			~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_160MHZ;
 	}
 
-	if (conn->bw_limit < IEEE80211_CONN_BW_LIMIT_320) {
+	if (conn->bw_limit < IEEE80211_CONN_BW_LIMIT_320 ||
+	    sband->band != NL80211_BAND_6GHZ) {
 		fixed.phy_cap_info[0] &=
 			~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
 		fixed.phy_cap_info[1] &=
-- 
2.52.0

Re: [PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band

[Johannes Berg]

On Thu, 2026-01-22 at 15:56 +0100, Nicolas Escande wrote:
> The spec (at least 802.11-be draft7) at section 9.4.2.323.3 says we should
> not set the 320MHz related fields when not operating on a 6GHz band. It's
> quite explicit for most of them. For example:
> 
> Bit 0 "Support For 320 MHz In 6 GHz" says "Reserved if the EHT
>       Capabilities element is indicating capabilities for the 2.4 GHz or
>       5 GHz bands."
> 
> Bit 22-24 "Number Of Sounding Dimensions (= 320 MHz)" says "Reserved if
>           the SU Beamformer subfield is 0 or the Support For 320 MHz In
>           6 GHz subfield in EHT Capabilities Information field does not
>           indicate support for a bandwidth of 320 MHz."
> 
> Bit 54 "Support Of EHT-MCS 15 In MRU" says about bit 3 "If 320 MHz is not
>         supported, then B3 is set to 0."
> 
> For bit 13-15 "Beamformee SS (= 320 MHz)" it's not explicit, but it makes
> little sense to special case the handling of this one.

Sure, but ...

> Fixes: 6239da18d2f9 ("wifi: mac80211: adjust EHT capa when lowering bandwidth")
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
>  net/mac80211/util.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 0c46009a3d63..996983f6815b 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -4426,7 +4426,8 @@ int ieee80211_put_eht_cap(struct sk_buff *skb,
>  			~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_160MHZ;
>  	}
>  
> -	if (conn->bw_limit < IEEE80211_CONN_BW_LIMIT_320) {
> +	if (conn->bw_limit < IEEE80211_CONN_BW_LIMIT_320 ||
> +	    sband->band != NL80211_BAND_6GHZ) {
>  		fixed.phy_cap_info[0] &=
>  			~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
>  		fixed.phy_cap_info[1] &=

How does this make any sense? The driver should just not advertise the
bit on its 2.4 and 5 GHz sbands?

johannes

Re: [PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band

[Nicolas Escande]

On Thu Jan 22, 2026 at 5:05 PM CET, Johannes Berg wrote:
> On Thu, 2026-01-22 at 15:56 +0100, Nicolas Escande wrote:
>> The spec (at least 802.11-be draft7) at section 9.4.2.323.3 says we should
>> not set the 320MHz related fields when not operating on a 6GHz band. It's
>> quite explicit for most of them. For example:
>> 
>> Bit 0 "Support For 320 MHz In 6 GHz" says "Reserved if the EHT
>>       Capabilities element is indicating capabilities for the 2.4 GHz or
>>       5 GHz bands."
>> 
>> Bit 22-24 "Number Of Sounding Dimensions (= 320 MHz)" says "Reserved if
>>           the SU Beamformer subfield is 0 or the Support For 320 MHz In
>>           6 GHz subfield in EHT Capabilities Information field does not
>>           indicate support for a bandwidth of 320 MHz."
>> 
>> Bit 54 "Support Of EHT-MCS 15 In MRU" says about bit 3 "If 320 MHz is not
>>         supported, then B3 is set to 0."
>> 
>> For bit 13-15 "Beamformee SS (= 320 MHz)" it's not explicit, but it makes
>> little sense to special case the handling of this one.
>
> Sure, but ...
>
>> Fixes: 6239da18d2f9 ("wifi: mac80211: adjust EHT capa when lowering bandwidth")
>> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
>> ---
>>  net/mac80211/util.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
>> index 0c46009a3d63..996983f6815b 100644
>> --- a/net/mac80211/util.c
>> +++ b/net/mac80211/util.c
>> @@ -4426,7 +4426,8 @@ int ieee80211_put_eht_cap(struct sk_buff *skb,
>>  			~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_160MHZ;
>>  	}
>>  
>> -	if (conn->bw_limit < IEEE80211_CONN_BW_LIMIT_320) {
>> +	if (conn->bw_limit < IEEE80211_CONN_BW_LIMIT_320 ||
>> +	    sband->band != NL80211_BAND_6GHZ) {
>>  		fixed.phy_cap_info[0] &=
>>  			~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
>>  		fixed.phy_cap_info[1] &=
>
> How does this make any sense? The driver should just not advertise the
> bit on its 2.4 and 5 GHz sbands?
>
> johannes

Well from a strictly spec point of view yes: "Reserved if the EHT
Capabilities element is indicating capabilities for the 2.4 GHz or 5 GHz bands."
doesn't leave much room for interpretation.

But it kinda of seems counter productive for this name "Support For 320 MHz In 6
GHz" as it seems to have be explicitely chosen to inform people that a colocated
AP exists on the 6Ghz band.

For context I initially encountered this problem on an ath12k AP which has a
single phy with both 5GHz & 6GHz bands available but only had a 5GHz AP started.
On such a platform, we set this '320MHz in 6G' operation on the 5GHz no matter
what beacause of the phy's capabilities.

So not sure how to adress this problem, it seems weird that the driver should
alter the EHT elem by himself to be honest.

Nico,

Re: [PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band

[Johannes Berg]

On Thu, 2026-01-22 at 17:38 +0100, Nicolas Escande wrote:
> For context I initially encountered this problem on an ath12k AP which has a
> single phy with both 5GHz & 6GHz bands available but only had a 5GHz AP started.
> On such a platform, we set this '320MHz in 6G' operation on the 5GHz no matter
> what beacause of the phy's capabilities.

But that's what I'm saying why it's a driver bug - the PHY capabilities
are advertised *per interface type* and *per band* by the driver. It
shouldn't set this one on 2.4/5 GHz bands.

johannes

Re: [PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band

[Nicolas Escande]

On Thu Jan 22, 2026 at 5:41 PM CET, Johannes Berg wrote:
> On Thu, 2026-01-22 at 17:38 +0100, Nicolas Escande wrote:
>> For context I initially encountered this problem on an ath12k AP which has a
>> single phy with both 5GHz & 6GHz bands available but only had a 5GHz AP started.
>> On such a platform, we set this '320MHz in 6G' operation on the 5GHz no matter
>> what beacause of the phy's capabilities.
>
> But that's what I'm saying why it's a driver bug - the PHY capabilities
> are advertised *per interface type* and *per band* by the driver. It
> shouldn't set this one on 2.4/5 GHz bands.
>

Arf I missed the per band part of the equation. I'll fix it there.
Sry for wasting your time.

> johannes

Nico,