[PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Nicolas Escande]

On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
realated features on the 5GHz band while it should not:

    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.

This should not happen as the spec at section 9.4.2.323.3 says we should
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

Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
 drivers/net/wireless/ath/ath12k/wmi.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 84c29e4896a4..14947fdb9813 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -4888,6 +4888,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;
 
@@ -4901,8 +4902,14 @@ 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 {
+		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[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
+	}
 
 	cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
 	cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);
-- 
2.52.0

Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Pablo MARTIN-GOMEZ]

Hello,

On 23/01/2026 15:42, 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:
>
>      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.
>
> This should not happen as the spec at section 9.4.2.323.3 says we should
> 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
>
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
>   drivers/net/wireless/ath/ath12k/wmi.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index 84c29e4896a4..14947fdb9813 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -4888,6 +4888,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;
>   
> @@ -4901,8 +4902,14 @@ 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 {
> +		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[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
> +	}
If you want to clear all 320 MHz fields, you'll also have to clear 
IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ and 
IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ (not sure why it is not done 
in mac80211)
>   
>   	cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
>   	cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);

Best regards,

Pablo MG

Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Johannes Berg]

On Fri, 2026-01-23 at 19:33 +0100, Pablo MARTIN-GOMEZ wrote:
> 
> > @@ -4901,8 +4902,14 @@ 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 {
> > +		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[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
> > +	}
> If you want to clear all 320 MHz fields, you'll also have to clear 
> IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ and 
> IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ (not sure why it is not done 
> in mac80211)
> 

This is, effectively, a firmware workaround. It doesn't belong into
mac80211. All other drivers just have their capabilities managed in the
driver anyway.

johannes

Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Pablo MARTIN-GOMEZ]

On 23/01/2026 20:08, Johannes Berg wrote:
> On Fri, 2026-01-23 at 19:33 +0100, Pablo MARTIN-GOMEZ wrote:
>>> @@ -4901,8 +4902,14 @@ 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 {
>>> +		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[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
>>> +	}
>> If you want to clear all 320 MHz fields, you'll also have to clear
>> IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ and
>> IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ (not sure why it is not done
>> in mac80211)
>>
> This is, effectively, a firmware workaround. It doesn't belong into
> mac80211. All other drivers just have their capabilities managed in the
> driver anyway.
>
> johannes

I wasn't talking about putting this patch in mac80211 (I've seen the 
discussion on the patch Nicolas sent on linux-wireless), I'm talking 
about the function `ieee80211_put_eht_cap` clearing the Beamformee SS 
and Sounding Dimension fields but not the Non-OFDMA UL MU-MIMO and MU 
Beamformer fields for each bandwidth.

Pablo

Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Johannes Berg]

On Fri, 2026-01-23 at 20:21 +0100, Pablo MARTIN-GOMEZ wrote:
> 
> > > > +	} else {
> > > > +		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[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
> > > > +	}
> > > If you want to clear all 320 MHz fields, you'll also have to clear
> > > IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ and
> > > IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ (not sure why it is not done
> > > in mac80211)
> > > 
> > This is, effectively, a firmware workaround. It doesn't belong into
> > mac80211. All other drivers just have their capabilities managed in the
> > driver anyway.
> > 
> > johannes
> 
> I wasn't talking about putting this patch in mac80211 (I've seen the 
> discussion on the patch Nicolas sent on linux-wireless), I'm talking 
> about the function `ieee80211_put_eht_cap` clearing the Beamformee SS 
> and Sounding Dimension fields but not the Non-OFDMA UL MU-MIMO and MU 
> Beamformer fields for each bandwidth.

Ah, you're asking why mac80211 doesn't clear those bits ... I guess it
just doesn't matter. If you're not on 320 MHz I'd guess the bits are
never checked, so it's not really relevant at all, although then could
argue that you only need the first line here as well.

johannes

Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Nicolas Escande]

On Fri Jan 23, 2026 at 8:29 PM CET, Johannes Berg wrote:
> On Fri, 2026-01-23 at 20:21 +0100, Pablo MARTIN-GOMEZ wrote:
>> 
>> > > > +	} else {
>> > > > +		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[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
>> > > > +	}
>> > > If you want to clear all 320 MHz fields, you'll also have to clear
>> > > IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ and
>> > > IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ (not sure why it is not done
>> > > in mac80211)
>> > > 

If the QCA guys are interrested I can post a v2 with the additionnal bits also
cleared.

>> > This is, effectively, a firmware workaround. It doesn't belong into
>> > mac80211. All other drivers just have their capabilities managed in the
>> > driver anyway.
>> > 
>> > johannes
>> 

Yep you made me realize that. So I tracked how to fix it in the underlying
driver and posted this patch.

>> I wasn't talking about putting this patch in mac80211 (I've seen the 
>> discussion on the patch Nicolas sent on linux-wireless), I'm talking 
>> about the function `ieee80211_put_eht_cap` clearing the Beamformee SS 
>> and Sounding Dimension fields but not the Non-OFDMA UL MU-MIMO and MU 
>> Beamformer fields for each bandwidth.
>
> Ah, you're asking why mac80211 doesn't clear those bits ... I guess it
> just doesn't matter. If you're not on 320 MHz I'd guess the bits are
> never checked, so it's not really relevant at all, although then could
> argue that you only need the first line here as well.

I you want Johannes, I can post a patch that also clears those bits in mac80211
>
> johannes

Nico,

Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band

[Johannes Berg]

On Mon, 2026-01-26 at 11:11 +0100, Nicolas Escande wrote:
> > Ah, you're asking why mac80211 doesn't clear those bits ... I guess it
> > just doesn't matter. If you're not on 320 MHz I'd guess the bits are
> > never checked, so it's not really relevant at all, although then could
> > argue that you only need the first line here as well.
> 
> I you want Johannes, I can post a patch that also clears those bits in mac80211
> 

I don't think it really matters much, though I think in some older cases
we might be clearing more related bits.

johannes