Linux wireless drivers development
 help / color / mirror / Atom feed
From: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
To: Nicolas Escande <nico.escande@gmail.com>, ath12k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
Date: Wed, 17 Jun 2026 10:33:14 +0530	[thread overview]
Message-ID: <3fb00a3b-2092-43d2-a8f8-9f934505dcee@oss.qualcomm.com> (raw)
In-Reply-To: <20260611084422.1511513-1-nico.escande@gmail.com>

On 6/11/2026 2:14 PM, Nicolas Escande wrote:
> On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
> realated features on the 5GHz band while it should not:


s/realated/related

> 
>      Wiphy phy1
>      [...]
>          Band 2:
>      [...]
>              EHT Iftypes: managed
>      [...]
>                  EHT PHY Capabilities: (0xe2ffdbe018778000):
>                      320MHz in 6GHz Supported
>      [...]
>                      Beamformee SS (320MHz): 7
>      [...]
>                      Number Of Sounding Dimensions (320MHz): 3
>      [...]
>                  EHT MCS/NSS: (0x22222222222222222200000000):
> 
> This is also reflected in the beacons sent by a mesh interface started on
> that band. They erroneously advertise 320MHZ support too.

s/320MHZ/320MHz

> 
> This should not happen as the spec at section 9.4.2.323.3 says we should

Reword the spec citation to: IEEE Std 802.11-2024, subclause 9.4.2.323.3 ...


> not set the 320MHz related fields when not operating on a 6GHz band.
> For example it says about Bit 0 "Support For 320 MHz In 6 GHz"
> 
>    "Reserved if the EHT Capabilities element is indicating capabilities for
>     the 2.4 GHz or 5 GHz bands."
> 
> Fix this by clearing the related bits when converting from WMI eht phy
> capabilities to mac80211 phy capabilities, for bands other than 6GHz.
> 
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
> 

The commit log mentions wrong `iw phy` output and wrong mesh beacon
advertisement, so this appears user visible. If that is the intended bug 
being fixed, please add a Fixes tag.

> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
> Changes from v1:
>    - rebased on ath-next
>    - clear all 6GHz / 320MHz related phy capabilities fields from the firmware
> ---
>   drivers/net/wireless/ath/ath12k/wmi.c | 17 ++++++++++++++++-
>   1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index 84a31b953db8..a8a4654c4f34 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -5154,6 +5154,7 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
>   				       __le32 cap_info_internal)
>   {
>   	struct ath12k_band_cap *cap_band = &pdev->cap.band[band];
> +	u8 *phy_cap = (u8 *)&cap_band->eht_cap_phy_info[0];
>   	u32 support_320mhz;
>   	u8 i;
>   
> @@ -5167,8 +5168,22 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
>   	for (i = 0; i < WMI_MAX_EHTCAP_PHY_SIZE; i++)
>   		cap_band->eht_cap_phy_info[i] = le32_to_cpu(cap_phy_info[i]);
>   
> -	if (band == NL80211_BAND_6GHZ)
> +	if (band == NL80211_BAND_6GHZ) {	
>   		cap_band->eht_cap_phy_info[0] |= support_320mhz;
> +	} else {
> +		/*
> +		 * It seems the firmware can report capabilities specific to
> +		 * 6GHz also for 5GHz, so lets explicitely clear them out.

The code comment should be less tentative, how about:

      /*
       * Firmware may report 6 GHz/320 MHz specific capabilities for
       * non-6 GHz bands, so explicitly clear them.
       */


> +		 */
> +		phy_cap[0] &= ~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
> +		phy_cap[1] &= ~IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK;
> +		phy_cap[2] &= ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
> +		phy_cap[3] &= ~IEEE80211_EHT_PHY_CAP3_SOUNDING_DIM_320MHZ_MASK;
> +		phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
> +		phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_EHT_DUP_6GHZ_SUPP;
> +		phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ;
> +		phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ;	;
> +	}
>   
>   	cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
>   	cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);


checkpatch warnings:
ERROR: trailing whitespace
#61: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5171:
+^Iif (band == NL80211_BAND_6GHZ) {^I$

WARNING: 'explicitely' may be misspelled - perhaps 'explicitly'?
#66: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5176:
+                * 6GHz also for 5GHz, so lets explicitely clear them out.
                                                ^^^^^^^^^^^

WARNING: space prohibited before semicolon
#75: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5185:
+               phy_cap[7] &= 
~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ;     ;

WARNING: Statements terminations use 1 semicolon
#75: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5185:
+               phy_cap[7] &= 
~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ;     ;



  reply	other threads:[~2026-06-17  5:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11  8:44 [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band Nicolas Escande
2026-06-17  5:03 ` Rameshkumar Sundaram [this message]
2026-06-17  8:45   ` 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=3fb00a3b-2092-43d2-a8f8-9f934505dcee@oss.qualcomm.com \
    --to=rameshkumar.sundaram@oss.qualcomm.com \
    --cc=ath12k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nico.escande@gmail.com \
    /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