From: "Nicolas Escande" <nico.escande@gmail.com>
To: "Pradeep Kumar Chitrapu" <quic_pradeepc@quicinc.com>,
<ath12k@lists.infradead.org>
Cc: <linux-wireless@vger.kernel.org>,
"P Praneesh" <quic_ppranees@quicinc.com>,
"Jeff Johnson" <quic_jjohnson@quicinc.com>
Subject: Re: [PATCH V13 8/9] wifi: ath12k: add support for 160 MHz bandwidth
Date: Mon, 02 Jun 2025 11:05:19 +0200 [thread overview]
Message-ID: <DABXEETZP415.3EDDINBHDH42A@gmail.com> (raw)
In-Reply-To: <b7d500e3-445e-455d-a74f-4ec3c7f3fde3@quicinc.com>
On Wed May 28, 2025 at 8:16 PM CEST, Pradeep Kumar Chitrapu wrote:
>
>
> On 5/22/2025 1:34 AM, Nicolas Escande wrote:
>> On Wed May 21, 2025 at 11:38 PM CEST, Pradeep Kumar Chitrapu wrote:
>> [...]
>>> Thanks Nicolas,
>>>
>>> I believe IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ mean only
>>> 80PLUS80 not both 160 and 80PLUS80 and STA must set
>>> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ flags for indicating 160 MHz
>>> support. Please correct me if my understanding is correct. However I
>>> agree that we must allow STA to connect irrespective of which flag STA
>>> sets as long as bandwidth is 160MHz. I see ath10k and ath11k also allows
>>> this by setting default phymode of MODE_11AC_VHT160 for BW
>>> ==IEEE80211_STA_RX_BW_160 case.
>>> I will make this change in next revision.
>>> Thanks
>>> Pradeep
>>
>> Hello Pradeep,
>>
>> Well this is quite unclear for me maybe Johannes or someone more aware of the
>> evolutions of the standard could shime in.
>>
>> From what I've gathered:
>> - the naming IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ implies both
>> which points it was the case when added
>> - and the original 802.11ac-2013 Table 8-183v states:
>> Set to 0 if the STA does not support either 160 or 80+80 MHz.
>> Set to 1 if the STA supports 160 MHz.
>> Set to 2 if the STA supports 160 MHz and 80+80 MHz.
>> The value 3 is reserved.
>>
>> Things get complicated after:
>> - later versions like 802.11-2020 have deprecated value 2 in favor of the new
>> Extendeed NSS BW feature
>> - Table 9-272 still implies both 160 & 80+80
>> - Table 11-23 & Table 11-24 implies only 80+80 but both talk about the
>> 'VHT Operation' Channel Width field and not the 'VHT Capabilities' Supported
>> Channel Width. And thoses had different values even in the first AC amendment
>>
>> So it feels like when no Extended NSS BW Support is used (first gen AC devices),
>> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ really means both 160 & 80+80
> Thanks Nicolas for detailed response.
> Request you to kindly review V14 series and let me know if it works?
>
> Thanks
> Pradeep
Hello Pradeep,
Yes your new version fixes the problem for me.
Thanks
next prev parent reply other threads:[~2025-06-02 9:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 17:48 [PATCH V13 0/9] wifi: ath12k: add MU-MIMO and 160 MHz bandwidth support Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 1/9] wifi: ath12k: push HE MU-MIMO params to hardware Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 2/9] wifi: ath12k: push EHT " Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 3/9] wifi: ath12k: move HE MCS mapper to a separate function Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 4/9] wifi: ath12k: generate rx and tx mcs maps for supported HE mcs Pradeep Kumar Chitrapu
2025-05-29 6:59 ` Uraj Sasan
2025-05-30 23:01 ` Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 5/9] wifi: ath12k: fix TX and RX MCS rate configurations in HE mode Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 6/9] wifi: ath12k: add support for setting fixed HE rate/GI/LTF Pradeep Kumar Chitrapu
2025-05-14 14:54 ` Jeff Johnson
2025-05-21 21:39 ` Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 7/9] wifi: ath12k: clean up 80P80 support Pradeep Kumar Chitrapu
2025-04-18 17:48 ` [PATCH V13 8/9] wifi: ath12k: add support for 160 MHz bandwidth Pradeep Kumar Chitrapu
2025-05-19 15:11 ` Nicolas Escande
2025-05-21 21:38 ` Pradeep Kumar Chitrapu
2025-05-22 8:34 ` Nicolas Escande
2025-05-28 18:16 ` Pradeep Kumar Chitrapu
2025-06-02 9:05 ` Nicolas Escande [this message]
2025-04-18 17:48 ` [PATCH V13 9/9] wifi: ath12k: add extended NSS bandwidth support for 160 MHz Pradeep Kumar Chitrapu
2025-04-18 18:48 ` [PATCH V13 0/9] wifi: ath12k: add MU-MIMO and 160 MHz bandwidth support Jeff Johnson
2025-04-28 16:20 ` Vasanthakumar Thiagarajan
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=DABXEETZP415.3EDDINBHDH42A@gmail.com \
--to=nico.escande@gmail.com \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_jjohnson@quicinc.com \
--cc=quic_ppranees@quicinc.com \
--cc=quic_pradeepc@quicinc.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;
as well as URLs for NNTP newsgroup(s).