From: Johannes Berg <johannes@sipsolutions.net>
To: Michal Sojka <sojkam1@fel.cvut.cz>, linux-wireless@vger.kernel.org
Cc: bernd.lehmann@volkswagen.de, s.sander@nordsys.de,
wireless-regdb@lists.infradead.org, ath9k-devel@lists.ath9k.org,
ath9k-devel@qca.qualcomm.com,
"Jan Kaisrlík" <kaisrja1@fel.cvut.cz>, "Jouni Malinen" <j@w1.fi>
Subject: Re: [PATCH v2 5/8] cfg80211: Add support for OCB-only channels
Date: Fri, 27 Nov 2015 09:33:58 +0100 [thread overview]
Message-ID: <1448613238.2531.12.camel@sipsolutions.net> (raw)
In-Reply-To: <1448303241-27747-6-git-send-email-sojkam1@fel.cvut.cz> (sfid-20151123_192810_015203_959DA591)
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote:
> #define NL80211_RRF_PASSIVE_SCAN NL80211_RRF_NO_IR
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 59cabc9..b1ab77a 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -804,7 +804,8 @@ static bool _cfg80211_reg_can_beacon(struct wiphy
> *wiphy,
> {
> bool res;
> u32 prohibited_flags = IEEE80211_CHAN_DISABLED |
> - IEEE80211_CHAN_RADAR;
> + IEEE80211_CHAN_RADAR |
> + IEEE80211_CHAN_OCB_ONLY;
So ... for the kernel, I don't *like* this approach, because it
requires touching every single driver, and every single person who
writes code in the future must be aware of the special handling for
this flag.
For userspace, however, this approach is simply impossible. Consider an
older version of wpa_supplicant, that queries the channel list and
isn't aware of the OCB_ONLY flag. This version would take the channel
list and build a scan request with it, only to get the scan rejected
since some channels it picked were only usable for OCB, as far as I can
tell.
I think the solution to this would be to redefine the CHAN_DISABLED
flag to mean "channel disabled for non-ocb mode" and add a
CHAN_OCB_ENABLED flag.
Then code that knows about OCB would simply not test CHAN_DISABLED, but
would instead test CHAN_OCB_ENABLED instead - and if that's clear OCB
would not be permitted.
However, this would have the side effect of enabling OCB *only* on OCB
channels, which might not be a good idea, for testing purposes one
might want to use the regular 2.4 or 5 GHz channels? If so, OCB could
still be made to do something like
ocb_usable = (flags & OCB_ENABLED) || !(flags & DISABLED);
or we could even make the channel list internally maintain a
CHAN_OCB_USABLE flag that essentially encodes the logic above.
In any case, this would collapse the patch down to modifying only OCB
code and nothing else, which is nice, and would keep existing userspace
working since it would just see disabled channels while ignoring the
OCB flag.
johannes
next prev parent reply other threads:[~2015-11-27 8:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 18:27 [PATCH v2 0/8] Regulatory and ath9k support for ITS-G5 band (5.9 GHz) Michal Sojka
2015-11-23 18:27 ` [PATCH v2 1/8] cfg80211: reg: Remove unused function parameter Michal Sojka
2015-11-23 18:27 ` [PATCH v2 2/8] cfg80211: Remove unused cfg80211_can_use_iftype_chan() Michal Sojka
2015-11-26 16:46 ` Johannes Berg
2015-11-23 18:27 ` [PATCH v2 3/8] cfg80211: reg: Refactor calculation of bandwidth flags Michal Sojka
2015-11-26 17:48 ` Johannes Berg
2015-11-23 18:27 ` [PATCH v2 4/8] cfg80211: reg: Properly handle rules for 5 and 10 MHz channels Michal Sojka
2015-11-26 17:51 ` Johannes Berg
2015-11-30 9:56 ` Jouni Malinen
2015-11-30 10:30 ` Johannes Berg
2015-11-23 18:27 ` [PATCH v2 5/8] cfg80211: Add support for OCB-only channels Michal Sojka
2015-11-27 8:33 ` Johannes Berg [this message]
2015-11-27 8:59 ` Michal Sojka
2015-11-23 18:27 ` [PATCH v2 6/8] cfg80211: reg: Add NL80211_RRF_USER_REGD_NEEDED flag Michal Sojka
2015-11-27 8:35 ` Johannes Berg
2015-11-27 9:43 ` Michal Sojka
2015-11-27 9:52 ` Johannes Berg
2015-11-23 18:27 ` [PATCH v2 7/8] cfg80211: Add Kconfig option for ITS-G5 band (5.9 GHz) Michal Sojka
2015-11-26 17:55 ` Johannes Berg
2015-11-26 21:10 ` Michal Sojka
2015-11-27 8:25 ` Johannes Berg
2015-11-27 8:44 ` Michal Sojka
2015-11-23 18:27 ` [PATCH v2 8/8] ath9k: Add support " Michal Sojka
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=1448613238.2531.12.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ath9k-devel@lists.ath9k.org \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=bernd.lehmann@volkswagen.de \
--cc=j@w1.fi \
--cc=kaisrja1@fel.cvut.cz \
--cc=linux-wireless@vger.kernel.org \
--cc=s.sander@nordsys.de \
--cc=sojkam1@fel.cvut.cz \
--cc=wireless-regdb@lists.infradead.org \
/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).