From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
To: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>,
"arend.vanspriel@broadcom.com" <arend.vanspriel@broadcom.com>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"avinashp@quantenna.com" <avinashp@quantenna.com>,
"sergey.matyukevich.os@quantenna.com"
<sergey.matyukevich.os@quantenna.com>
Subject: Re: [PATCH] nl80211: add an option to allow MFP without requiring it
Date: Mon, 14 Aug 2017 13:36:36 -0700 [thread overview]
Message-ID: <ac8bfacb-9b2c-c3e5-12df-a5f7b4711bce@quantenna.com> (raw)
In-Reply-To: <1502741597.8162.1.camel@intel.com>
On 08/14/2017 01:13 PM, Grumbach, Emmanuel wrote:
>> It is kind of not clear right now for drivers where to get
>> information from:
>> - NL attributes passed from userspace and forwarded to a driver
>
> Since those exist, it seems to make more sense to me to use those
> rather than any in-driver decided policy. Usually, deciding upon
> policies from lower levels is frowned upon I'd say.
I agree, what I mean is that drivers should know where to take this
information from, if there are multiple sources.
An example are HT/VHT capabilities for start_ap command: they can be
parsed directly by drivers by looking at beacon's IEs in
"cfg80211_ap_settings". At the same time those are also parsed by
nl80211 which fills cfg80211_ap_settings::ht_cap,
cfg80211_ap_settings::vht_cap.
Why HT/VHT caps are not passed directly from usespace as one of NL
attributes? I guess because there is not much point in it since
userspace passes entire IE set anyway, which can be used by lower levels.
>
>> - IEs passed from userspace, parsed by nl80211 and forwarded to a
>> driver
>> - IEs that are passed from userspace and parsed by drivers directly
>>
>>>
>>> Thanks,
>>> Arend
>>
>>
next prev parent reply other threads:[~2017-08-14 20:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 13:49 [PATCH] nl80211: add an option to allow MFP without requiring it Emmanuel Grumbach
2017-08-14 17:14 ` Kalle Valo
2017-08-14 18:13 ` Grumbach, Emmanuel
2017-08-15 7:16 ` Kalle Valo
2017-08-15 7:49 ` Grumbach, Emmanuel
2017-08-15 8:03 ` Grumbach, Emmanuel
2017-08-14 18:44 ` Igor Mitsyanko
2017-08-14 18:44 ` Igor Mitsyanko
2017-08-14 19:22 ` Arend van Spriel
2017-08-14 20:08 ` Igor Mitsyanko
2017-08-14 20:13 ` Grumbach, Emmanuel
2017-08-14 20:36 ` Igor Mitsyanko [this message]
2017-08-15 6:12 ` Grumbach, Emmanuel
2017-08-15 8:14 ` [PATCH v2] " Emmanuel Grumbach
2017-08-15 8:28 ` [PATCH v3] " Emmanuel Grumbach
2017-08-18 12:31 ` [PATCH v4 12/19] " 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=ac8bfacb-9b2c-c3e5-12df-a5f7b4711bce@quantenna.com \
--to=igor.mitsyanko.os@quantenna.com \
--cc=arend.vanspriel@broadcom.com \
--cc=avinashp@quantenna.com \
--cc=emmanuel.grumbach@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=sergey.matyukevich.os@quantenna.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).