linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Muna Sinada <quic_msinada@quicinc.com>
Cc: linux-wireless@vger.kernel.org, Aloka Dixit <quic_alokad@quicinc.com>
Subject: Re: [RFC 1/4] wifi: nl80211: advertise RU puncturing support to userspace
Date: Thu, 19 Jan 2023 16:31:56 +0100	[thread overview]
Message-ID: <b98e76416ce4edba699f2bb4d456489e69ceeff1.camel@sipsolutions.net> (raw)
In-Reply-To: <1670006154-6092-2-git-send-email-quic_msinada@quicinc.com>

On Fri, 2022-12-02 at 10:35 -0800, Muna Sinada wrote:
> From: Aloka Dixit <quic_alokad@quicinc.com>
> [...]
> Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>

You should probably add your S-o-b since you handled the patch.

> + * @ru_punct_supp_bw: Whether the driver supports RU puncturing, and if so,
> + *     for which bandwidths.
> 

I find the definition in nl80211 to be clearer which talks about minimum
bandwidth, to be honest.

>   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> + *

unneeded blank line?

> +/**
> + * enum nl80211_ru_punct_supp_bw - Bandwidths supporting preamble puncturing
> + *
> + * @NL80211_RU_PUNCT_NOT_SUPP: preamble puncturing is not supported

I see why you did this (cfg80211) but can't say I like it since in
netlink terms we'd just not include the attribute in that case ...

> + * @NL80211_RU_PUNCT_SUPP_BW_80: puncturing supported within channels of at
> + *	least 80 MHz bandwidth
> + * @NL80211_RU_PUNCT_SUPP_BW_160: puncturing supported within channels of at
> + *	least 160 MHz bandwidth
> + * @NL80211_RU_PUNCT_SUPP_BW_320: puncturing supported within 320 MHz.
> + */
> +enum nl80211_ru_punct_supp_bw {
> +	NL80211_RU_PUNCT_NOT_SUPP,
> +	NL80211_RU_PUNCT_SUPP_BW_80,
> +	NL80211_RU_PUNCT_SUPP_BW_160,
> +	NL80211_RU_PUNCT_SUPP_BW_320,
> +};

Btw why is this a minimum bandwidth - couldn't this be a bitmap of
bandwidths for example? I mean, is there a technical requirement that if
you do it in 80, you can do it in 160? It's probably true in general,
but maybe we can just completely avoid defining the new enum by saying

 u32 puncturing_widths;

and put there BIT(NL80211_CHAN_WIDTH_80), BIT(NL80211_CHAN_WIDTH_160)
and BIT(NL80211_CHAN_WIDTH_320) - and maybe even
BIT(NL80211_CHAN_WIDTH_80P80) which could conceivably be harder/less
supported, and you haven't covered (is it part of your 80+, 160+ or not
covered at all?)

That way also 0 == not supported in cfg80211.

johannes

  parent reply	other threads:[~2023-01-19 15:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 18:35 [RFC 0/4] Static RU Puncturing Muna Sinada
2022-12-02 18:35 ` [RFC 1/4] wifi: nl80211: advertise RU puncturing support to userspace Muna Sinada
2022-12-14  8:02   ` Kalle Valo
2023-01-19 15:31   ` Johannes Berg [this message]
2022-12-02 18:35 ` [RFC 2/4] wifi: cfg80211: RU puncturing bitmap Muna Sinada
2023-01-19 15:34   ` Johannes Berg
2022-12-02 18:35 ` [RFC 3/4] wifi: nl80211: validate " Muna Sinada
2023-01-19 15:37   ` Johannes Berg
2023-01-20  0:42     ` Aloka Dixit
2023-01-20  9:20       ` Johannes Berg
2023-01-23 18:28         ` Aloka Dixit
2022-12-02 18:35 ` [RFC 4/4] wifi: mac80211: Handle RU Puncturing information Muna Sinada
2023-01-19 15:40   ` Johannes Berg

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=b98e76416ce4edba699f2bb4d456489e69ceeff1.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=quic_alokad@quicinc.com \
    --cc=quic_msinada@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).