From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Luca Coelho <luca@coelho.fi>, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org,
Liad Kaufman <liad.kaufman@intel.com>,
Johannes Berg <johannes.berg@intel.com>,
Ilan Peer <ilan.peer@intel.com>, Ido Yariv <idox.yariv@intel.com>
Subject: Re: [RFC 1/3] cfg80211: Add support for HE
Date: Fri, 25 May 2018 12:34:55 +0200 [thread overview]
Message-ID: <5B07E6CF.8070000@broadcom.com> (raw)
In-Reply-To: <b1d344f5f5fa2797fa5b931f019bb7f3bd18b904.camel@coelho.fi>
On 5/25/2018 12:11 PM, Luca Coelho wrote:
>>> +static int
>>> > >+nl80211_send_ift_data(struct sk_buff *msg,
>>> > >+ const struct ieee80211_sband_iftype_data *iftdata)
>> >
>> >make it nl80211_send_iftype_data.
> Okay, I'll replace all ift instances to iftype.
My comment is mainly about function names.
>>> > > static int nl80211_send_band_rateinfo(struct sk_buff *msg,
>>> > > struct ieee80211_supported_band *sband)
>>> > > {
>>> > >@@ -1353,6 +1383,32 @@ static int nl80211_send_band_rateinfo(struct sk_buff *msg,
>>> > > sband->vht_cap.cap)))
>>> > > return -ENOBUFS;
>>> > >
>>> > >+ if (sband->n_iftype_data) {
>>> > >+ struct nlattr *nl_iftype_data =
>>> > >+ nla_nest_start(msg, NL80211_BAND_ATTR_IFTYPE_DATA);
>>> > >+ int err;
>>> > >+
>>> > >+ if (!nl_iftype_data)
>>> > >+ return -ENOBUFS;
>>> > >+
>>> > >+ for (i = 0; i < sband->n_iftype_data; i++) {
>>> > >+ struct nlattr *iftdata;
>>> > >+
>>> > >+ iftdata = nla_nest_start(msg, i + 1);
>>> > >+ if (!iftdata)
>>> > >+ return -ENOBUFS;
>> >
>> >bit inconsistent dealing with error path. Here errno is returned....
>> >
>>> > >@@ -4490,6 +4549,19 @@ static bool nl80211_put_sta_rate(struct sk_buff *msg, struct rate_info *info,
>>> > > if (info->flags & RATE_INFO_FLA
> return false;
>>> > >+ } else if (info->flags & RATE_INFO_FLAGS_HE_MCS) {
>>> > >+ if (nla_put_u8(msg, NL80211_RATE_INFO_HE_MCS, info->mcs))
>>> > >+ return false;
>> >
>> >... and here bool is returned. Admittedly, this seems to have been the
>> >case already before this patch.
Sure.
>
>>> > >diff --git a/net/wireless/util.c b/net/wireless/util.c
>>> > >index d112e9a89364..b66a68a41cd6 100644
>>> > >--- a/net/wireless/util.c
>>> > >+++ b/net/wireless/util.c
>>> > >@@ -4,6 +4,7 @@
>>> > > *
>>> > > * Copyright 2007-2009 Johannes Berg<johannes@sipsolutions.net>
>>> > > * Copyright 2013-2014 Intel Mobile Communications GmbH
>>> > >+ * Copyright 2017 Intel Deutschland GmbH
>>> > > */
>>> > > #include <linux/export.h>
>>> > > #include <linux/bitops.h>
>>> > >@@ -1142,6 +1143,85 @@ static u32 cfg80211_calculate_bitrate_vht(struct rate_info *rate)
>>> > > return 0;
>>> > > }
>>> > >
>>> > >+static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate)
>>> > >+{
>>> > >+#define SCALE 2048
>>> > >+ u16 mcs_divisors[12] = {
>>> > >+ 34133, /* 16.666666... */
>>> > >+ 17067, /* 8.333333... */
>>> > >+ 11378, /* 5.555555... */
>>> > >+ 8533, /* 4.166666... */
>>> > >+ 5689, /* 2.777777... */
>>> > >+ 4267, /* 2.083333... */
>>> > >+ 3923, /* 1.851851... */
>>> > >+ 3413, /* 1.666666... */
>>> > >+ 2844, /* 1.388888... */
>>> > >+ 2560, /* 1.250000... */
>>> > >+ 2276, /* 1.111111... */
>>> > >+ 2048, /* 1.000000... */
>>> > >+ };
>>> > >+ u32 rates_160M[3] = { 960777777, 907400000, 816666666 };
>>> > >+ u32 rates_969[3] = { 480388888, 453700000, 408333333 };
>>> > >+ u32 rates_484[3] = { 229411111, 216666666, 195000000 };
>>> > >+ u32 rates_242[3] = { 114711111, 108333333, 97500000 };
>>> > >+ u32 rates_106[3] = { 40000000, 37777777, 34000000 };
>>> > >+ u32 rates_52[3] = { 18820000, 17777777, 16000000 };
>>> > >+ u32 rates_26[3] = { 9411111, 8888888, 8000000 };
>>> > >+ u64 tmp;
>>> > >+ u32 result;
>>> > >+
>>> > >+ if (WARN_ON_ONCE(rate->mcs > 11))
>>> > >+ return 0;
>>> > >+
>>> > >+ if (WARN_ON_ONCE(rate->he_gi > NL80211_RATE_INFO_HE_GI_3_2))
>>> > >+ return 0;
>>> > >+ if (WARN_ON_ONCE(rate->he_ru_alloc >
>>> > >+ NL80211_RATE_INFO_HE_RU_ALLOC_2x996))
>>> > >+ return 0;
>>> > >+ if (WARN_ON_ONCE(rate->nss < 1 || rate->nss > 8))
>>> > >+ return 0;
>>> > >+
>>> > >+ if (rate->bw == RATE_INFO_BW_160)
>>> > >+ result = rates_160M[rate->he_gi];
>>> > >+ else if (rate->bw == RATE_INFO_BW_80 ||
>>> > >+ (rate->bw == RATE_INFO_BW_HE_RU &&
>>> > >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_996))
>>> > >+ result = rates_969[rate->he_gi];
>>> > >+ else if (rate->bw == RATE_INFO_BW_40 ||
>>> > >+ (rate->bw == RATE_INFO_BW_HE_RU &&
>>> > >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_484))
>>> > >+ result = rates_484[rate->he_gi];
>>> > >+ else if (rate->bw == RATE_INFO_BW_20 ||
>>> > >+ (rate->bw == RATE_INFO_BW_HE_RU &&
>>> > >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_242))
>>> > >+ result = rates_242[rate->he_gi];
>>> > >+ else if (rate->bw == RATE_INFO_BW_HE_RU &&
>>> > >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_106)
>>> > >+ result = rates_106[rate->he_gi];
>>> > >+ else if (rate->bw == RATE_INFO_BW_HE_RU &&
>>> > >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_52)
>>> > >+ result = rates_52[rate->he_gi];
>>> > >+ else if (rate->bw == RATE_INFO_BW_HE_RU &&
>>> > >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_26)
>>> > >+ result = rates_26[rate->he_gi];
>>> > >+ else if (WARN(1, "invalid HE MCS: bw:%d, ru:%d\n",
>>> > >+ rate->bw, rate->he_ru_alloc))
>>> > >+ return 0;
>>> > >+
>> >
>> >Could consider shifts below iso multiply/division.
>>> > >+ /* now scale to the appropriate MCS */
>>> > >+ tmp = result;
>>> > >+ tmp *= SCALE;
>> > tmp <<= 11;
>>> > >+ do_div(tmp, mcs_divisors[rate->mcs]);
>>> > >+ result = tmp;
>>> > >+
>>> > >+ /* and take NSS, DCM into account */
>>> > >+ result = (result * rate->nss) / 8;
>> > result = (result * rate->nss) >> 3;
>>> > >+ if (rate->he_dcm)
>>> > >+ result /= 2;
>> > result >>= 1;
>>> > >+
>>> > >+ return result;
>>> > >+}
>>> > >+
> I'm not sure I agree. These are divisions and not really shifts, so
> IMHO it's clearer as is. This is not a hot path and the compiler will
> probably optimize it in to shifts if possible anyway. So I won't
> change it in my next version. Feel free to yell if you disagree (and
> have a good argument :P).
Not really. It is just that everything was power of 2, but indeed it is
not used in data path.
> Thanks a lot for your review!
No problemo.
Gr. AvS
next prev parent reply other threads:[~2018-05-25 10:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 14:05 [RFC 0/3] cfg80211/mac80211: add support for IEEE802.11ax Luca Coelho
2018-05-18 14:05 ` [RFC 1/3] cfg80211: Add support for HE Luca Coelho
2018-05-21 19:47 ` Arend van Spriel
2018-05-25 10:11 ` Luca Coelho
2018-05-25 10:34 ` Arend van Spriel [this message]
2018-05-25 19:51 ` Luca Coelho
2018-05-28 9:05 ` Arend van Spriel
2018-05-18 14:05 ` [RFC 2/3] radiotap: add structs " Luca Coelho
2018-05-18 14:05 ` [RFC 3/3] mac80211: add support " Luca Coelho
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=5B07E6CF.8070000@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=idox.yariv@intel.com \
--cc=ilan.peer@intel.com \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=liad.kaufman@intel.com \
--cc=linux-wireless@vger.kernel.org \
--cc=luca@coelho.fi \
/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).