* [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
@ 2026-06-11 8:44 Nicolas Escande
2026-06-17 5:03 ` Rameshkumar Sundaram
0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Escande @ 2026-06-11 8:44 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
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>
---
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.
+ */
+ 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]);
--
2.54.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
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
2026-06-17 8:45 ` Nicolas Escande
0 siblings, 1 reply; 3+ messages in thread
From: Rameshkumar Sundaram @ 2026-06-17 5:03 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
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; ;
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
2026-06-17 5:03 ` Rameshkumar Sundaram
@ 2026-06-17 8:45 ` Nicolas Escande
0 siblings, 0 replies; 3+ messages in thread
From: Nicolas Escande @ 2026-06-17 8:45 UTC (permalink / raw)
To: Rameshkumar Sundaram, ath12k; +Cc: linux-wireless
On Wed Jun 17, 2026 at 7:03 AM CEST, Rameshkumar Sundaram wrote:
> 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
sure
>
>>
>> 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
sure
>
>>
>> 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.
>
Well I did not put a fixes tag as this does not create any real problems
per say. It does not impede any sta to connect in any way. Only
people explicitely parsing the beacons IE see an unexpected value.
So unless you guys really insist, I'd just skip it. Otherwise the 2
candidates are are:
- 1476014fadb6 ("wifi: ath12k: WMI support to process EHT capabilities")
It added the EHT caps parsing but lacked any logic to handle 6G so
that means backporting would imply a different patch than this one
- d4e244c85e45 ("wifi: ath12k: enable 320 MHz bandwidth for 6 GHz band
in EHT PHY capability for WCN7850"). This one added 6GHz support and
is the one I'm fixing but for a different chipset in mind than mine.
>> 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.
> */
>
sure
>
>> + */
>> + 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; ;
And all that will be fixed obviously
Thanks for the review
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-17 8:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2026-06-17 8:45 ` Nicolas Escande
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox