linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).