public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: "Nicolas Escande" <nico.escande@gmail.com>
To: "Johannes Berg" <johannes@sipsolutions.net>,
	"Nicolas Escande" <nico.escande@gmail.com>,
	<linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band
Date: Thu, 22 Jan 2026 17:38:01 +0100	[thread overview]
Message-ID: <DFV9KI49QEP2.2TMVJXR5EK0B7@gmail.com> (raw)
In-Reply-To: <829488acfdbf7ecfe6418bfb2c5669dae18392ed.camel@sipsolutions.net>

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,

  reply	other threads:[~2026-01-22 16:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 14:56 [PATCH] wifi: mac80211: do not set 320MHz EHT capabilities on non 6GHz band Nicolas Escande
2026-01-22 16:05 ` Johannes Berg
2026-01-22 16:38   ` Nicolas Escande [this message]
2026-01-22 16:41     ` Johannes Berg
2026-01-23 13:47       ` Nicolas Escande

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFV9KI49QEP2.2TMVJXR5EK0B7@gmail.com \
    --to=nico.escande@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox