VHT (11ac) regulatory new design. VHT channel center freq, bandwidth and
primary channel are used to decide if that channel config is permitted
in current regulatory domain.
Signed-off-by: Mahesh Palivela <[email protected]>
---
Implementation of review comments by Johannes.
include/net/cfg80211.h | 37 ++++++++++++++++
net/wireless/reg.c | 109 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 60597cf..50180e0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -83,6 +83,25 @@ enum ieee80211_band {
};
/**
+ * enum ieee80211_chan_width - channel bandwidths
+ *
+ * @IEEE80211_CHAN_WIDTH_20MHZ_NOHT: 20 MHz chan bandwidth No HT
+ * @IEEE80211_CHAN_WIDTH_20MHZ: 20 MHz chan bandwidth
+ * @IEEE80211_CHAN_WIDTH_40MHZ: 40 MHz chan bandwidth
+ * @IEEE80211_CHAN_WIDTH_80MHZ: 80 MHz chan bandwidth
+ * @IEEE80211_CHAN_WIDTH_160MHZ: 160 MHz chan bandwidth
+ * @IEEE80211_CHAN_WIDTH_80P80MHZ: 80+80 MHz chan bandwidth
+ */
+enum ieee80211_chan_width {
+ IEEE80211_CHAN_WIDTH_20MHZ_NOHT,
+ IEEE80211_CHAN_WIDTH_20MHZ,
+ IEEE80211_CHAN_WIDTH_40MHZ,
+ IEEE80211_CHAN_WIDTH_80MHZ,
+ IEEE80211_CHAN_WIDTH_160MHZ,
+ IEEE80211_CHAN_WIDTH_80P80MHZ
+};
+
+/**
* enum ieee80211_channel_flags - channel flags
*
* Channel flags set by the regulatory control code.
@@ -144,6 +163,24 @@ struct ieee80211_channel {
};
/**
+ * struct ieee80211_channel_config - channel config definition
+ *
+ * This structure describes channel configuration
+ *
+ * @chan_width1: channel bandwidth
+ * @center_freq1: center frequency of 1 st frequency segment
+ * @center_freq2: center frequency of 2 nd frequency segment
+ * Used only for 80+80 MHz combination
+ * @prim_chan_freq: primary channel frequency
+ */
+struct ieee80211_channel_config {
+ enum ieee80211_chan_width chan_width;
+ u16 center_freq1;
+ u16 center_freq2;
+ u16 prim_chan_freq;
+};
+
+/**
* enum ieee80211_rate_flags - rate flags
*
* Hardware/specification flags for rates. These are structured
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index c6e0d46..31d6f7a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1124,6 +1124,115 @@ static void reg_process_beacons(struct wiphy *wiphy)
wiphy_update_beacon_reg(wiphy);
}
+static bool reg_fits_reg_rule_sec_chans(struct wiphy *wiphy,
+ u32 center_freq,
+ u32 bw_khz,
+ const struct ieee80211_regdomain *regd)
+{
+ int r;
+ const struct ieee80211_reg_rule *reg_rule;
+ const struct ieee80211_freq_range *freq_range;
+ struct ieee80211_channel *chan;
+ u32 left_end_freq, right_end_freq;
+
+ WARN_ON(!center_freq);
+ WARN_ON(!bw_khz);
+
+ assert_reg_lock();
+
+ r = freq_reg_info_regd(wiphy,
+ center_freq,
+ bw_khz,
+ ®_rule,
+ regd);
+
+ if (r) {
+ REG_DBG_PRINT("Couldn't find reg rule for freq %d KHz"
+ "and %d MHz wide channel\n",
+ center_freq,
+ KHZ_TO_MHZ(bw_khz));
+ return false;
+ }
+
+ freq_range = ®_rule->freq_range;
+
+ if (freq_range->max_bandwidth_khz < bw_khz)
+ return false;
+
+ /* find left and right arms of center freq */
+ left_end_freq = center_freq - (bw_khz/2);
+ right_end_freq = center_freq + (bw_khz/2);
+
+ /* left_end_freq and right_end_freq are edge of left and right
+ * channels. Get center freq of left and right channels
+ * by adding 10MHz to left_end_freq and subtracting 10 MHZ from
+ * right_end_freq.
+ */
+ left_end_freq += MHZ_TO_KHZ(10);
+ right_end_freq -= MHZ_TO_KHZ(10);
+
+ /* find out all possible secondary channels */
+ while (left_end_freq < right_end_freq) {
+ chan = ieee80211_get_channel(wiphy, left_end_freq);
+ if (chan == NULL ||
+ chan->flags & IEEE80211_CHAN_DISABLED) {
+ return false;
+ }
+ left_end_freq -= MHZ_TO_KHZ(20);
+ }
+
+ return true;
+}
+
+bool reg_chan_use_permitted(struct wiphy *wiphy,
+ struct ieee80211_channel_config *chan_config,
+ const struct ieee80211_regdomain *regd)
+{
+ u32 desired_bw_khz = MHZ_TO_KHZ(20);
+ bool ret;
+
+ /* get chan BW from config */
+ switch (chan_config->chan_width) {
+ case IEEE80211_CHAN_WIDTH_20MHZ_NOHT:
+ case IEEE80211_CHAN_WIDTH_20MHZ:
+ desired_bw_khz = MHZ_TO_KHZ(20);
+ break;
+
+ case IEEE80211_CHAN_WIDTH_40MHZ:
+ desired_bw_khz = MHZ_TO_KHZ(40);
+ break;
+
+ case IEEE80211_CHAN_WIDTH_80MHZ:
+ case IEEE80211_CHAN_WIDTH_80P80MHZ:
+ desired_bw_khz = MHZ_TO_KHZ(80);
+ break;
+
+ case IEEE80211_CHAN_WIDTH_160MHZ:
+ desired_bw_khz = MHZ_TO_KHZ(160);
+ break;
+ default:
+ REG_DBG_PRINT("Invalid channel width %d\n",
+ chan_config->chan_width);
+ return false;
+ }
+
+ ret = reg_fits_reg_rule_sec_chans(wiphy,
+ chan_config->center_freq1,
+ desired_bw_khz,
+ regd);
+
+ if (ret == false)
+ return ret;
+
+ if (chan_config->chan_width == IEEE80211_CHAN_WIDTH_80P80MHZ) {
+ ret = reg_fits_reg_rule_sec_chans(wiphy,
+ chan_config->center_freq2,
+ desired_bw_khz,
+ regd);
+ }
+ return ret;
+}
+
static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
{
if (!chan)
On Tue, 2012-09-25 at 12:06 -0700, Luis R. Rodriguez wrote:
> > You've got to be kidding? Runtime cost of this is negligible, we only
> > execute the test when we switch channels which happens very
> > infrequently.
>
> Well considering P2P technologies slowly blooming I would disagree
> that channel changes are going to be infrequent. Then we also have
> scanning which can happen any time you move away from your AP and at a
> specific interval. Are we going to remove the capability to use each
> channel as cached value and always ask cfg80211 it we can move on?
They're still going to be infrequent, you're not going to switch
channels (in mac80211) for every other packet :-) Even if you were to do
channel switching every couple of seconds, which is really unlikely and
will kill all performance, the calculation overhead wouldn't matter.
johannes
On 09/14/2012 02:11 AM, Luis R. Rodriguez wrote:
> On Mon, Sep 10, 2012 at 3:06 AM, Mahesh Palivela <[email protected]> wrote:
>> VHT (11ac) regulatory new design. VHT channel center freq, bandwidth and
>> primary channel are used to decide if that channel config is permitted in
>> current regulatory domain.
>
> Please include me on cfg80211 regulatory changes in the future. My
> review below. But in short I am not in agreement with this approach
> for a few reasons explained below. I removed all hunks from my reply
> for which I had no comments for.
>
Stanislaw felt flags based approach is not scalable, so is this new
approach.
>> + *
>> + * @chan_width1: channel bandwidth
>
> Comment here is chan_width1 but you have only chan_width
>
Removed 1.
>> + freq_range = ®_rule->freq_range;
>> +
>> + if (freq_range->max_bandwidth_khz < bw_khz)
>> + return false;
>
> Do you really need the above two lines ? The reg_does_bw_fit() should
> have figured this out no?
>
This is still required. what if the rule says max allowed BW is 40 MHz
and our desired is 80 MHz.
>> +
>> + /* find left and right arms of center freq */
>> + left_end_freq = center_freq - (bw_khz/2);
>> + right_end_freq = center_freq + (bw_khz/2);
>> +
>> + /* left_end_freq and right_end_freq are edge of left and right
>> + * channels. Get center freq of left and right channels
>> + * by adding 10MHz to left_end_freq and subtracting 10 MHZ from
>> + * right_end_freq.
>> + */
>> + left_end_freq += MHZ_TO_KHZ(10);
>> + right_end_freq -= MHZ_TO_KHZ(10);
>
> Note: you are starting your left_end_freq here at the very first IEEE
> channel from the left of the regulatory rule.
>
Not really. what if centre_freq is chan 46, BW is 80 MHz then chan 38
will be left_end. Plus 10 Mhz will give chan 40.
>> + /* find out all possible secondary channels */
>> + while (left_end_freq < right_end_freq) {
>
> Should this be <= ? Otherwise the last 20 MHz IEEE channel would not
> be checked, no ?
>
Agree. will change that..
>> + chan = ieee80211_get_channel(wiphy, left_end_freq);
>> + if (chan == NULL ||
>> + chan->flags & IEEE80211_CHAN_DISABLED) {
>> + return false;
>> + }
>> + left_end_freq -= MHZ_TO_KHZ(20);
>
> From what I read here you are sweeping left to right for all 20 MHz
> channels and you are allowing for the VHT channel of bw_khz bandwidth
> only if all 20 MHz IEEE channels in between are allowed. Is that
> correct?
>
Yes Luis.
>> + }
>> +
>> + return true;
>> +}
>> +
>> +bool reg_chan_use_permitted(struct wiphy *wiphy,
>> + struct ieee80211_channel_config *chan_config,
>> + const struct ieee80211_regdomain *regd)
>> +{
>> + u32 desired_bw_khz = MHZ_TO_KHZ(20);
>> + bool ret;
>> +
>> + /* get chan BW from config */
>>
>> + switch (chan_config->chan_width) {
>> + case IEEE80211_CHAN_WIDTH_20MHZ_NOHT:
>> + case IEEE80211_CHAN_WIDTH_20MHZ:
>> + desired_bw_khz = MHZ_TO_KHZ(20);
>> + break;
>> +
>> + case IEEE80211_CHAN_WIDTH_40MHZ:
>> + desired_bw_khz = MHZ_TO_KHZ(40);
>> + break;
>> +
>> + case IEEE80211_CHAN_WIDTH_80MHZ:
>> + case IEEE80211_CHAN_WIDTH_80P80MHZ:
>> + desired_bw_khz = MHZ_TO_KHZ(80);
>> + break;
>> +
>> + case IEEE80211_CHAN_WIDTH_160MHZ:
>> + desired_bw_khz = MHZ_TO_KHZ(160);
>> + break;
>> + default:
>> + REG_DBG_PRINT("Invalid channel width %d\n",
>> + chan_config->chan_width);
>> + return false;
>> + }
>> +
>> + ret = reg_fits_reg_rule_sec_chans(wiphy,
>> + chan_config->center_freq1,
>> + desired_bw_khz,
>> + regd);
>> +
>>
>> + if (ret == false)
>> + return ret;
>> +
>> + if (chan_config->chan_width == IEEE80211_CHAN_WIDTH_80P80MHZ) {
>> + ret = reg_fits_reg_rule_sec_chans(wiphy,
>> + chan_config->center_freq2,
>> + desired_bw_khz,
>> + regd);
>>
>> + }
>
> And for the special case of 80 MHz + 80 MHz split channels (ie, not
> contiguous) you then spin off the check for each segment of 80 MHz
> channels.
>
> But no code here uses it. Based on the previous threads on this VHT
> regulatory topic I get the impression your goal is to end up using
> this code to determine whether or not a non-HT, HT or VHT channel is
> allowed for and based on feedback it seems that the objective is to
> use this code eventually to do dynamic run time checks of whether or
> not we're allowed to use this channel configuration setup. If so then
> I have a few comments for that.
Yes. That's the objective. we are not calling these functions anywhere
yet. Once this proposal is accepted then I want to spread further. But I
am confused now....
>
> Although VHT complicates the regulatory checks, to the extent you
> check for valid 20 MHz IEEE channels in between a VHT wide channel,
> the IEEE spec actually only allows in practice certain VHT
> arrangements. I've asked for shiny diagrams that have this laid out
> clearly and simple but unfortunately we do not have one, but such
> simple static arrangements are apparently specified on the spec, its
> not clear to me where exactly though... Technically then if we wanted
> to keep a static cached early check of allowed channels maps for VHT
> we should be able to have a bitmap representation of the allowed IEEE
> VHT channel configurations and upon initialization / regulatory change
> update this bitmap to determine if we're allowed to use the new
> arrangement. The approach you use is also fine and while it does allow
> for flexibility to do add more technologies one should consider the
> penalty incurred at doing these computations at run time. The run time
> impact is no issue if its done just once but consider changing
> channels and how often we can do this. Consider a device now with one
> radio but two virtual devices and each one doing their own set of
> scans and two different types of HT / VHT configurations. This means
> the code you just wrote will become a real hot path -- used for
> anything that has to do with any channel change. The purpose of the
> flags are to remove that run time penalty, so if we can take into
> consideration more the nature of how we VHT channels are allowed and
> how IEEE decided to simplify the arrangements for VHT then likely
> keeping flags may make sense then. That is, not all VHT arrangements
> are possible, only a subset, and it seems fairly trivial and
> reasonable to me to do this upon regulatory change only once rather
> than at every channel change.
>
> And as for the question: "What about the future? Will we see 320 MHz
> wide channels in 2020? :)"
>
> I'm told through a shiny crystal ball: let's not expect 320 MHz channels.
>
> So I'd rather keep this simple and also due to the fact that VHT
> channels are static just try to use a bitmap for them and check for it
> at regulatory change.
>
I agree Luis. Limiting the flags to a subset is fine with me. Hope no
more disagreements.
> Luis
>
On Fri, 2012-09-14 at 13:48 +0530, Mahesh Palivela wrote:
> > Although VHT complicates the regulatory checks, to the extent you
> > check for valid 20 MHz IEEE channels in between a VHT wide channel,
> > the IEEE spec actually only allows in practice certain VHT
> > arrangements. I've asked for shiny diagrams that have this laid out
> > clearly and simple but unfortunately we do not have one, but such
> > simple static arrangements are apparently specified on the spec, its
> > not clear to me where exactly though... Technically then if we wanted
> > to keep a static cached early check of allowed channels maps for VHT
> > we should be able to have a bitmap representation of the allowed IEEE
> > VHT channel configurations and upon initialization / regulatory change
> > update this bitmap to determine if we're allowed to use the new
> > arrangement. The approach you use is also fine and while it does allow
> > for flexibility to do add more technologies one should consider the
> > penalty incurred at doing these computations at run time. The run time
> > impact is no issue if its done just once but consider changing
> > channels and how often we can do this. Consider a device now with one
> > radio but two virtual devices and each one doing their own set of
> > scans and two different types of HT / VHT configurations. This means
> > the code you just wrote will become a real hot path -- used for
> > anything that has to do with any channel change. The purpose of the
> > flags are to remove that run time penalty, so if we can take into
> > consideration more the nature of how we VHT channels are allowed and
> > how IEEE decided to simplify the arrangements for VHT then likely
> > keeping flags may make sense then. That is, not all VHT arrangements
> > are possible, only a subset, and it seems fairly trivial and
> > reasonable to me to do this upon regulatory change only once rather
> > than at every channel change.
> >
> > And as for the question: "What about the future? Will we see 320 MHz
> > wide channels in 2020? :)"
> >
> > I'm told through a shiny crystal ball: let's not expect 320 MHz channels.
> >
> > So I'd rather keep this simple and also due to the fact that VHT
> > channels are static just try to use a bitmap for them and check for it
> > at regulatory change.
> >
>
> I agree Luis. Limiting the flags to a subset is fine with me. Hope no
> more disagreements.
I'm not convinced :-)
Today, we have people who want to use wifi on other parts of the
spectrum, like somewhere in the 800 MHz range for example. If that gets
properly integrated into drivers (rather than pretending it's actually
2.4 GHz) then you may want to do something different here, and those
channels would never actually have IEEE defined 80 MHz rules.
Also, those definitions are arbitrary for interoperability and don't
reflect regulatory rules. Yes, it may be easier today to just pretend
that regulatory rules only matter for IEEE defined operation, but I'm
not convinced that we really should have definitions here in the
regulatory database that really only cover specific IEEE 802.11
channels. The regulatory database was designed to be at least a bit more
generic and in fact we always treated it as max bandwidth etc.
I think just using the 802.11 rules here would be artificially limiting
the expressiveness of the regulatory database.
johannes
On Mon, Sep 24, 2012 at 3:48 AM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2012-09-17 at 11:56 -0700, Luis R. Rodriguez wrote:
>
>> > I'm not convinced :-)
>> >
>> > Today, we have people who want to use wifi on other parts of the
>> > spectrum, like somewhere in the 800 MHz range for example. If that gets
>> > properly integrated into drivers (rather than pretending it's actually
>> > 2.4 GHz) then you may want to do something different here, and those
>> > channels would never actually have IEEE defined 80 MHz rules.
>>
>> So we'd have HT20 and HT40 only for 800 MHz?
>
> Why would we want to restrict bandwidth use to the band we're operating
> in at all? Fundamentally, the question, in terms of regulatory, is:
>
> "Can I use a XY MHz around XYZ MHz?"
>
> It isn't really "Can I use VHT 80 on channel 6".
True, but we won't enable HT on non-HT cards, and so on. As much as we
can assume code is non IEEE specific cfg80211 builds on IEEE framework
and adding support to HT-foo or HT-bar to any band would require some
changes today.
>> > Also, those definitions are arbitrary for interoperability and don't
>> > reflect regulatory rules.
>>
>> It seems easier to implement supporting checking for a static set of
>> VHT arrangements rather than figuring out all theoretically possible
>> arrangements given that most other arrangements would be unused /
>> unimplemented / not-supported.
>
> I think it's only superficially easier since we define regulatory rules
> in terms of spectrum usage, and not in terms of IEEE channels.
I disagree here. Superficially it would indeed make things easier for
IEEE usage but in practice also it would make run time checks faster.
With a dynamic run time checker you are looking at a higher complex
operation at channel change time. That is what I am concerned about
ultimately.
>> > Yes, it may be easier today to just pretend
>> > that regulatory rules only matter for IEEE defined operation, but I'm
>> > not convinced that we really should have definitions here in the
>> > regulatory database that really only cover specific IEEE 802.11
>> > channels.
>>
>> Agreed, but what I am proposing doesn't necessarily push us to push
>> anything IEEE specific into the wireless regulatory database, but it
>> does however push us to implement IEEE specific use cases on cfg80211.
>
> Well, since the regulatory framework is now part of cfg80211 the line is
> a bit blurred here,
Well I consider regulatory code as code not on the Linux kernel and
cfg80211 regulatory code as IEEE 802.11 regulatory code. The regdb can
surely still be used on other subsystems, and surely can be shared
between them, but today the only user is IEEE 802.11
> but I don't see why a regulatory check should be
> restricted to 802.11 channels either, even if it uses the 802.11 defines
> to do the check?
cfg80211 deals with 802.11 ?
> On the contrary, I think that if we frame the question
> above in terms of 802.11 when asking the regulatory framework, then
> we'll most likely end up with a regulatory framework that is 802.11
> specific.
Agreed but I think cfg80211 regulatory code already is 802.11
specific, but not the userspace stuff. If we have a reason to make and
separate the cfg80211 regulatory code to be non-802.11 specific I'm
fine by that, but what's the use case so far and for what gain?
Luis
On Mon, 2012-09-17 at 11:56 -0700, Luis R. Rodriguez wrote:
> > I'm not convinced :-)
> >
> > Today, we have people who want to use wifi on other parts of the
> > spectrum, like somewhere in the 800 MHz range for example. If that gets
> > properly integrated into drivers (rather than pretending it's actually
> > 2.4 GHz) then you may want to do something different here, and those
> > channels would never actually have IEEE defined 80 MHz rules.
>
> So we'd have HT20 and HT40 only for 800 MHz?
Why would we want to restrict bandwidth use to the band we're operating
in at all? Fundamentally, the question, in terms of regulatory, is:
"Can I use a XY MHz around XYZ MHz?"
It isn't really "Can I use VHT 80 on channel 6".
> > Also, those definitions are arbitrary for interoperability and don't
> > reflect regulatory rules.
>
> It seems easier to implement supporting checking for a static set of
> VHT arrangements rather than figuring out all theoretically possible
> arrangements given that most other arrangements would be unused /
> unimplemented / not-supported.
I think it's only superficially easier since we define regulatory rules
in terms of spectrum usage, and not in terms of IEEE channels.
> > Yes, it may be easier today to just pretend
> > that regulatory rules only matter for IEEE defined operation, but I'm
> > not convinced that we really should have definitions here in the
> > regulatory database that really only cover specific IEEE 802.11
> > channels.
>
> Agreed, but what I am proposing doesn't necessarily push us to push
> anything IEEE specific into the wireless regulatory database, but it
> does however push us to implement IEEE specific use cases on cfg80211.
Well, since the regulatory framework is now part of cfg80211 the line is
a bit blurred here, but I don't see why a regulatory check should be
restricted to 802.11 channels either, even if it uses the 802.11 defines
to do the check? On the contrary, I think that if we frame the question
above in terms of 802.11 when asking the regulatory framework, then
we'll most likely end up with a regulatory framework that is 802.11
specific.
johannes
On Mon, 2012-09-24 at 16:24 -0700, Luis R. Rodriguez wrote:
> > Why would we want to restrict bandwidth use to the band we're operating
> > in at all? Fundamentally, the question, in terms of regulatory, is:
> >
> > "Can I use a XY MHz around XYZ MHz?"
> >
> > It isn't really "Can I use VHT 80 on channel 6".
>
> True, but we won't enable HT on non-HT cards, and so on. As much as we
> can assume code is non IEEE specific cfg80211 builds on IEEE framework
> and adding support to HT-foo or HT-bar to any band would require some
> changes today.
Not really, most cards also don't even assume that you only do 40 MHz on
a channel that it's permitted on. The hardware will (mostly) be happy to
do HT40- on channel 44, even if the 802.11 spec says that you should do
HT40+ only on that channel.
> > I think it's only superficially easier since we define regulatory rules
> > in terms of spectrum usage, and not in terms of IEEE channels.
>
> I disagree here. Superficially it would indeed make things easier for
> IEEE usage but in practice also it would make run time checks faster.
> With a dynamic run time checker you are looking at a higher complex
> operation at channel change time. That is what I am concerned about
> ultimately.
You've got to be kidding? Runtime cost of this is negligible, we only
execute the test when we switch channels which happens very
infrequently.
> > Well, since the regulatory framework is now part of cfg80211 the line is
> > a bit blurred here,
>
> Well I consider regulatory code as code not on the Linux kernel and
> cfg80211 regulatory code as IEEE 802.11 regulatory code. The regdb can
> surely still be used on other subsystems, and surely can be shared
> between them, but today the only user is IEEE 802.11
That's not really true though since the entire regdb handling is also
part of cfg80211, so I think we should at least pretend to think about
other spectrum use (or admit we don't care about other technologies,
which is probably closer to the truth). Regardless though, if userspace
gives us the right information for use of very wide channels, then the
internal checks must fall to checking the spectrum permissions anyway,
instead of iterating the list of possible 802.11 channels.
> > On the contrary, I think that if we frame the question
> > above in terms of 802.11 when asking the regulatory framework, then
> > we'll most likely end up with a regulatory framework that is 802.11
> > specific.
>
> Agreed but I think cfg80211 regulatory code already is 802.11
> specific, but not the userspace stuff. If we have a reason to make and
> separate the cfg80211 regulatory code to be non-802.11 specific I'm
> fine by that, but what's the use case so far and for what gain?
Ok so basically you do want to say that this in-kernel code doesn't care
about other technologies, and if you want to use the regulatory database
for other things you have to separate out the current code into "db
handling" and "permission checking". I'm fine with that.
Still though, I fail to see how it helps? If you start from a database
that has just frequency ranges & information about those ranges, you
have to make a determination based on this information, for the channels
you want to use.
I'm proposing that we make that determination when we want to use a
channel, and don't really worry about the 802.11 rules, we can enforce
those in wpa_supplicant/hostapd as well, for example, like we actually
do today.
What you're proposing (as far as I understand) is that we iterate the
list of possible channels according to the 802.11 rules, and then make
*the same* determination up-front.
I fail to see the big difference that would make the latter easier,
since it falls back to the same decision algorithm.
johannes
On Mon, Sep 10, 2012 at 3:06 AM, Mahesh Palivela <[email protected]> wrote:
> VHT (11ac) regulatory new design. VHT channel center freq, bandwidth and
> primary channel are used to decide if that channel config is permitted in
> current regulatory domain.
Please include me on cfg80211 regulatory changes in the future. My
review below. But in short I am not in agreement with this approach
for a few reasons explained below. I removed all hunks from my reply
for which I had no comments for.
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -144,6 +163,24 @@ struct ieee80211_channel {
> };
>
> /**
> + * struct ieee80211_channel_config - channel config definition
> + *
> + * This structure describes channel configuration
> + *
> + * @chan_width1: channel bandwidth
Comment here is chan_width1 but you have only chan_width
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index c6e0d46..31d6f7a 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1124,6 +1124,115 @@ static void reg_process_beacons(struct wiphy *wiphy)
> wiphy_update_beacon_reg(wiphy);
> }
>
> +static bool reg_fits_reg_rule_sec_chans(struct wiphy *wiphy,
> + u32 center_freq,
> + u32 bw_khz,
>
> + const struct ieee80211_regdomain
> *regd)
> +{
> + int r;
> + const struct ieee80211_reg_rule *reg_rule;
> + const struct ieee80211_freq_range *freq_range;
> + struct ieee80211_channel *chan;
> + u32 left_end_freq, right_end_freq;
> +
> + WARN_ON(!center_freq);
> + WARN_ON(!bw_khz);
> +
> + assert_reg_lock();
>
> +
> + r = freq_reg_info_regd(wiphy,
> + center_freq,
> + bw_khz,
>
> + ®_rule,
> + regd);
> +
> + if (r) {
> + REG_DBG_PRINT("Couldn't find reg rule for freq %d KHz"
> + "and %d MHz wide channel\n",
> + center_freq,
> + KHZ_TO_MHZ(bw_khz));
>
> + return false;
> + }
> +
> + freq_range = ®_rule->freq_range;
> +
> + if (freq_range->max_bandwidth_khz < bw_khz)
> + return false;
Do you really need the above two lines ? The reg_does_bw_fit() should
have figured this out no?
> +
> + /* find left and right arms of center freq */
> + left_end_freq = center_freq - (bw_khz/2);
> + right_end_freq = center_freq + (bw_khz/2);
> +
> + /* left_end_freq and right_end_freq are edge of left and right
> + * channels. Get center freq of left and right channels
> + * by adding 10MHz to left_end_freq and subtracting 10 MHZ from
> + * right_end_freq.
> + */
> + left_end_freq += MHZ_TO_KHZ(10);
> + right_end_freq -= MHZ_TO_KHZ(10);
Note: you are starting your left_end_freq here at the very first IEEE
channel from the left of the regulatory rule.
> + /* find out all possible secondary channels */
> + while (left_end_freq < right_end_freq) {
Should this be <= ? Otherwise the last 20 MHz IEEE channel would not
be checked, no ?
> + chan = ieee80211_get_channel(wiphy, left_end_freq);
> + if (chan == NULL ||
> + chan->flags & IEEE80211_CHAN_DISABLED) {
> + return false;
> + }
> + left_end_freq -= MHZ_TO_KHZ(20);
>From what I read here you are sweeping left to right for all 20 MHz
channels and you are allowing for the VHT channel of bw_khz bandwidth
only if all 20 MHz IEEE channels in between are allowed. Is that
correct?
> + }
> +
> + return true;
> +}
> +
> +bool reg_chan_use_permitted(struct wiphy *wiphy,
> + struct ieee80211_channel_config *chan_config,
> + const struct ieee80211_regdomain *regd)
> +{
> + u32 desired_bw_khz = MHZ_TO_KHZ(20);
> + bool ret;
> +
> + /* get chan BW from config */
>
> + switch (chan_config->chan_width) {
> + case IEEE80211_CHAN_WIDTH_20MHZ_NOHT:
> + case IEEE80211_CHAN_WIDTH_20MHZ:
> + desired_bw_khz = MHZ_TO_KHZ(20);
> + break;
> +
> + case IEEE80211_CHAN_WIDTH_40MHZ:
> + desired_bw_khz = MHZ_TO_KHZ(40);
> + break;
> +
> + case IEEE80211_CHAN_WIDTH_80MHZ:
> + case IEEE80211_CHAN_WIDTH_80P80MHZ:
> + desired_bw_khz = MHZ_TO_KHZ(80);
> + break;
> +
> + case IEEE80211_CHAN_WIDTH_160MHZ:
> + desired_bw_khz = MHZ_TO_KHZ(160);
> + break;
> + default:
> + REG_DBG_PRINT("Invalid channel width %d\n",
> + chan_config->chan_width);
> + return false;
> + }
> +
> + ret = reg_fits_reg_rule_sec_chans(wiphy,
> + chan_config->center_freq1,
> + desired_bw_khz,
> + regd);
> +
>
> + if (ret == false)
> + return ret;
> +
> + if (chan_config->chan_width == IEEE80211_CHAN_WIDTH_80P80MHZ) {
> + ret = reg_fits_reg_rule_sec_chans(wiphy,
> + chan_config->center_freq2,
> + desired_bw_khz,
> + regd);
>
> + }
And for the special case of 80 MHz + 80 MHz split channels (ie, not
contiguous) you then spin off the check for each segment of 80 MHz
channels.
But no code here uses it. Based on the previous threads on this VHT
regulatory topic I get the impression your goal is to end up using
this code to determine whether or not a non-HT, HT or VHT channel is
allowed for and based on feedback it seems that the objective is to
use this code eventually to do dynamic run time checks of whether or
not we're allowed to use this channel configuration setup. If so then
I have a few comments for that.
Although VHT complicates the regulatory checks, to the extent you
check for valid 20 MHz IEEE channels in between a VHT wide channel,
the IEEE spec actually only allows in practice certain VHT
arrangements. I've asked for shiny diagrams that have this laid out
clearly and simple but unfortunately we do not have one, but such
simple static arrangements are apparently specified on the spec, its
not clear to me where exactly though... Technically then if we wanted
to keep a static cached early check of allowed channels maps for VHT
we should be able to have a bitmap representation of the allowed IEEE
VHT channel configurations and upon initialization / regulatory change
update this bitmap to determine if we're allowed to use the new
arrangement. The approach you use is also fine and while it does allow
for flexibility to do add more technologies one should consider the
penalty incurred at doing these computations at run time. The run time
impact is no issue if its done just once but consider changing
channels and how often we can do this. Consider a device now with one
radio but two virtual devices and each one doing their own set of
scans and two different types of HT / VHT configurations. This means
the code you just wrote will become a real hot path -- used for
anything that has to do with any channel change. The purpose of the
flags are to remove that run time penalty, so if we can take into
consideration more the nature of how we VHT channels are allowed and
how IEEE decided to simplify the arrangements for VHT then likely
keeping flags may make sense then. That is, not all VHT arrangements
are possible, only a subset, and it seems fairly trivial and
reasonable to me to do this upon regulatory change only once rather
than at every channel change.
And as for the question: "What about the future? Will we see 320 MHz
wide channels in 2020? :)"
I'm told through a shiny crystal ball: let's not expect 320 MHz channels.
So I'd rather keep this simple and also due to the fact that VHT
channels are static just try to use a bitmap for them and check for it
at regulatory change.
Luis
On Mon, Sep 17, 2012 at 8:34 AM, Johannes Berg
<[email protected]> wrote:
> On Fri, 2012-09-14 at 13:48 +0530, Mahesh Palivela wrote:
>
>> > Although VHT complicates the regulatory checks, to the extent you
>> > check for valid 20 MHz IEEE channels in between a VHT wide channel,
>> > the IEEE spec actually only allows in practice certain VHT
>> > arrangements. I've asked for shiny diagrams that have this laid out
>> > clearly and simple but unfortunately we do not have one, but such
>> > simple static arrangements are apparently specified on the spec, its
>> > not clear to me where exactly though... Technically then if we wanted
>> > to keep a static cached early check of allowed channels maps for VHT
>> > we should be able to have a bitmap representation of the allowed IEEE
>> > VHT channel configurations and upon initialization / regulatory change
>> > update this bitmap to determine if we're allowed to use the new
>> > arrangement. The approach you use is also fine and while it does allow
>> > for flexibility to do add more technologies one should consider the
>> > penalty incurred at doing these computations at run time. The run time
>> > impact is no issue if its done just once but consider changing
>> > channels and how often we can do this. Consider a device now with one
>> > radio but two virtual devices and each one doing their own set of
>> > scans and two different types of HT / VHT configurations. This means
>> > the code you just wrote will become a real hot path -- used for
>> > anything that has to do with any channel change. The purpose of the
>> > flags are to remove that run time penalty, so if we can take into
>> > consideration more the nature of how we VHT channels are allowed and
>> > how IEEE decided to simplify the arrangements for VHT then likely
>> > keeping flags may make sense then. That is, not all VHT arrangements
>> > are possible, only a subset, and it seems fairly trivial and
>> > reasonable to me to do this upon regulatory change only once rather
>> > than at every channel change.
>> >
>> > And as for the question: "What about the future? Will we see 320 MHz
>> > wide channels in 2020? :)"
>> >
>> > I'm told through a shiny crystal ball: let's not expect 320 MHz channels.
>> >
>> > So I'd rather keep this simple and also due to the fact that VHT
>> > channels are static just try to use a bitmap for them and check for it
>> > at regulatory change.
>> >
>>
>> I agree Luis. Limiting the flags to a subset is fine with me. Hope no
>> more disagreements.
>
> I'm not convinced :-)
>
> Today, we have people who want to use wifi on other parts of the
> spectrum, like somewhere in the 800 MHz range for example. If that gets
> properly integrated into drivers (rather than pretending it's actually
> 2.4 GHz) then you may want to do something different here, and those
> channels would never actually have IEEE defined 80 MHz rules.
So we'd have HT20 and HT40 only for 800 MHz?
> Also, those definitions are arbitrary for interoperability and don't
> reflect regulatory rules.
It seems easier to implement supporting checking for a static set of
VHT arrangements rather than figuring out all theoretically possible
arrangements given that most other arrangements would be unused /
unimplemented / not-supported.
> Yes, it may be easier today to just pretend
> that regulatory rules only matter for IEEE defined operation, but I'm
> not convinced that we really should have definitions here in the
> regulatory database that really only cover specific IEEE 802.11
> channels.
Agreed, but what I am proposing doesn't necessarily push us to push
anything IEEE specific into the wireless regulatory database, but it
does however push us to implement IEEE specific use cases on cfg80211.
> The regulatory database was designed to be at least a bit more
> generic and in fact we always treated it as max bandwidth etc.
I don't think this would deviate us away from it though. Where would
that happen?
> I think just using the 802.11 rules here would be artificially limiting
> the expressiveness of the regulatory database.
Agreed, but in so far as cfg80211 is concerned, as a consumer it can
surely use IEEE definitions in its own domain, no?
Luis
On 09/26/2012 12:36 AM, Luis R. Rodriguez wrote:
>
> OK lets go with dynamic poo checks.
>
Ok. I will continue with the dynamic permitted channel config from
regulatory.
> Luis
>
On Tue, Sep 25, 2012 at 12:16 AM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2012-09-24 at 16:24 -0700, Luis R. Rodriguez wrote:
>
>> > Why would we want to restrict bandwidth use to the band we're operating
>> > in at all? Fundamentally, the question, in terms of regulatory, is:
>> >
>> > "Can I use a XY MHz around XYZ MHz?"
>> >
>> > It isn't really "Can I use VHT 80 on channel 6".
>>
>> True, but we won't enable HT on non-HT cards, and so on. As much as we
>> can assume code is non IEEE specific cfg80211 builds on IEEE framework
>> and adding support to HT-foo or HT-bar to any band would require some
>> changes today.
>
> Not really, most cards also don't even assume that you only do 40 MHz on
> a channel that it's permitted on. The hardware will (mostly) be happy to
> do HT40- on channel 44, even if the 802.11 spec says that you should do
> HT40+ only on that channel.
Heh yeah...
>> > I think it's only superficially easier since we define regulatory rules
>> > in terms of spectrum usage, and not in terms of IEEE channels.
>>
>> I disagree here. Superficially it would indeed make things easier for
>> IEEE usage but in practice also it would make run time checks faster.
>> With a dynamic run time checker you are looking at a higher complex
>> operation at channel change time. That is what I am concerned about
>> ultimately.
>
> You've got to be kidding? Runtime cost of this is negligible, we only
> execute the test when we switch channels which happens very
> infrequently.
Well considering P2P technologies slowly blooming I would disagree
that channel changes are going to be infrequent. Then we also have
scanning which can happen any time you move away from your AP and at a
specific interval. Are we going to remove the capability to use each
channel as cached value and always ask cfg80211 it we can move on?
>> > Well, since the regulatory framework is now part of cfg80211 the line is
>> > a bit blurred here,
>>
>> Well I consider regulatory code as code not on the Linux kernel and
>> cfg80211 regulatory code as IEEE 802.11 regulatory code. The regdb can
>> surely still be used on other subsystems, and surely can be shared
>> between them, but today the only user is IEEE 802.11
>
> That's not really true though since the entire regdb handling is also
> part of cfg80211, so I think we should at least pretend to think about
> other spectrum use (or admit we don't care about other technologies,
> which is probably closer to the truth).
No you're right, the handling is purely technology agnostic and I've
always tried to keep it that way. Its just that as time went on it
started seeming like other technologies didn't want to use it or have
a way to use it. They certainly can and I'm willing to commit to
centralizing it and making a fine line but I just have't found use
cases for other technologies yet. I do suspect they will come hungry
one day looking for a solution though.
> Regardless though, if userspace
> gives us the right information for use of very wide channels, then the
> internal checks must fall to checking the spectrum permissions anyway,
> instead of iterating the list of possible 802.11 channels.
This is subjective and I prefer what you suggest, I do -- its just the
overhead I'm concerned over dynamic checks at run time channel change.
If you really feel its not going to be an issue then by all means,
lets do go for dynamic checks.
>> > On the contrary, I think that if we frame the question
>> > above in terms of 802.11 when asking the regulatory framework, then
>> > we'll most likely end up with a regulatory framework that is 802.11
>> > specific.
>>
>> Agreed but I think cfg80211 regulatory code already is 802.11
>> specific, but not the userspace stuff. If we have a reason to make and
>> separate the cfg80211 regulatory code to be non-802.11 specific I'm
>> fine by that, but what's the use case so far and for what gain?
>
> Ok so basically you do want to say that this in-kernel code doesn't care
> about other technologies, and if you want to use the regulatory database
> for other things you have to separate out the current code into "db
> handling" and "permission checking". I'm fine with that.
Yup. I've just been waiting for technologies to catch up looking for
what we have. They seem to be slow though.
> Still though, I fail to see how it helps? If you start from a database
> that has just frequency ranges & information about those ranges, you
> have to make a determination based on this information, for the channels
> you want to use.
True and in fact there are other technologies we have considered
integrating to help with efficient spectrum use and using the kernel
as a broker / helper with this, consider the frequency broker:
http://wireless.kernel.org/en/developers/FrequencyBroker
This was proposed in 2007 and at that time at least we envisioned
possibly sharing with BT channel use maps, and at times BT devices
could be informed through a firmware API that *is* required by the BT
spec to tell the device to avoid using certain channels (in our case
802.11 channels). This would in turn have allowed Linux, for example,
to deal with an OS level and device agnostic level of bluetooth
coexistance through channel skipping, one of the bt coex mechanisms:
http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
However obviously no one cared enough to implement this. But its
there... and yes I do foresee us requiring it, eventually.
> I'm proposing that we make that determination when we want to use a
> channel, and don't really worry about the 802.11 rules, we can enforce
> those in wpa_supplicant/hostapd as well, for example, like we actually
> do today.
That's fine, if we can ensure we won't incur a huge penalty at channel change :D
> What you're proposing (as far as I understand) is that we iterate the
> list of possible channels according to the 802.11 rules, and then make
> *the same* determination up-front.
Well consider it a cache of understood rules through a state machine.
We would clear the state machine regulatory cache upon a regulatory
change, but future checks if the state machine does not change would
enable you to very quickly move around spectrum with an O(1) check.
But -- similar ideas were spawned in networking, consider the routing
cache which is now nuked -- so maybe the cache benefits are just
theoretical and only provides a warm mental fuzzy feeling, in practice
it may be negligible and actually making things more complex.
> I fail to see the big difference that would make the latter easier,
> since it falls back to the same decision algorithm.
OK lets go with dynamic poo checks.
Luis