[RFC 0/2] VHT regulatory

[RFC 0/2] VHT regulatory

[Johannes Berg]

This allows wide bandwidth on the world roaming domain
(with a proposed change to the db.txt file parsing) and
enables (wide) bandwidth checking against the current
regulatory domain.

It's not entirely clear to me which regdom we should be
checking but I'm obviously not changing that logic, I'm
just not sure if wiphy->regd vs. cfg80211_regdomain is
handled correctly or what that even means ...

Also, if a driver has restrictions on VHT channel use,
say it doesn't allow arbitrary 80+80 MHz combinations,
I'm not sure how to handle that.

Thoughts? :-)

johannes

[RFC 1/2] regulatory: allow arbitrary channel widths

[Johannes Berg]

From: Johannes Berg <johannes.berg@intel.com>

There aren't any channel width restrictions in the
2.4 GHz band (except the natural ones by the (sub)band
boundaries), nor do default restrictions in the 5 GHz
band make sense when limited to passive scan/no IBSS
etc.

Allow passing NL80211_NO_REG_BANDWIDTH_LIMIT as the
max_bandwidth_khz and make that mean no restrictions.
Use it for the default world roaming regdomain.

Also make the awk script accept "NL" for "no limit"
and substitute NL80211_NO_REG_BANDWIDTH_LIMIT.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 include/net/regulatory.h     |  5 ++-
 include/uapi/linux/nl80211.h |  4 ++-
 net/wireless/genregdb.awk    |  5 ++-
 net/wireless/reg.c           | 77 +++++++++++++++++++++++---------------------
 4 files changed, 52 insertions(+), 39 deletions(-)

diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index f17ed59..06c4c10 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -122,7 +122,10 @@ struct ieee80211_regdomain {
 {							\
 	.freq_range.start_freq_khz = MHZ_TO_KHZ(start),	\
 	.freq_range.end_freq_khz = MHZ_TO_KHZ(end),	\
-	.freq_range.max_bandwidth_khz = MHZ_TO_KHZ(bw),	\
+	.freq_range.max_bandwidth_khz =			\
+		(bw) == NL80211_NO_REG_BANDWIDTH_LIMIT ?\
+			NL80211_NO_REG_BANDWIDTH_LIMIT :\
+			MHZ_TO_KHZ(bw),			\
 	.power_rule.max_antenna_gain = DBI_TO_MBI(gain),\
 	.power_rule.max_eirp = DBM_TO_MBM(eirp),	\
 	.flags = reg_flags,				\
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5470171..331cfb3 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2070,7 +2070,7 @@ enum nl80211_reg_type {
  * 	in KHz. This is not a center a frequency but an actual regulatory
  * 	band edge.
  * @NL80211_ATTR_FREQ_RANGE_MAX_BW: maximum allowed bandwidth for this
- * 	frequency range, in KHz.
+ * 	frequency range, in KHz, or %NL80211_NO_REG_BANDWIDTH_LIMIT.
  * @NL80211_ATTR_POWER_RULE_MAX_ANT_GAIN: the maximum allowed antenna gain
  * 	for a given frequency range. The value is in mBi (100 * dBi).
  * 	If you don't have one then don't send this.
@@ -2096,6 +2096,8 @@ enum nl80211_reg_rule_attr {
 	NL80211_REG_RULE_ATTR_MAX = __NL80211_REG_RULE_ATTR_AFTER_LAST - 1
 };
 
+#define NL80211_NO_REG_BANDWIDTH_LIMIT	0xffffffff
+
 /**
  * enum nl80211_sched_scan_match_attr - scheduled scan match attributes
  * @__NL80211_SCHED_SCAN_MATCH_ATTR_INVALID: attribute number 0 is reserved
diff --git a/net/wireless/genregdb.awk b/net/wireless/genregdb.awk
index 9392f8c..301ec36 100644
--- a/net/wireless/genregdb.awk
+++ b/net/wireless/genregdb.awk
@@ -57,6 +57,9 @@ active && /^[ \t]*\(/ {
 	end = $3
 	bw = $5
 	sub(/\),/, "", bw)
+	if (bw == "NL") {
+		bw = "NL80211_NO_REG_BANDWIDTH_LIMIT"
+	}
 	gain = $6
 	sub(/\(/, "", gain)
 	sub(/,/, "", gain)
@@ -107,7 +110,7 @@ active && /^[ \t]*\(/ {
 		}
 	}
 	flags = flags "0"
-	printf "\t\tREG_RULE(%d, %d, %d, %d, %d, %s),\n", start, end, bw, gain, power, flags
+	printf "\t\tREG_RULE(%d, %d, %s, %d, %d, %s),\n", start, end, bw, gain, power, flags
 	rules++
 }
 
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 041f22c..422b93e 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -172,29 +172,29 @@ static const struct ieee80211_regdomain world_regdom = {
 	.alpha2 =  "00",
 	.reg_rules = {
 		/* IEEE 802.11b/g, channels 1..11 */
-		REG_RULE(2412-10, 2462+10, 40, 6, 20, 0),
-		/* IEEE 802.11b/g, channels 12..13. No HT40
-		 * channel fits here. */
-		REG_RULE(2467-10, 2472+10, 20, 6, 20,
-			NL80211_RRF_PASSIVE_SCAN |
-			NL80211_RRF_NO_IBSS),
+		REG_RULE(2412-10, 2462+10, NL80211_NO_REG_BANDWIDTH_LIMIT,
+			 6, 20, 0),
+		/* IEEE 802.11b/g, channels 12..13. */
+		REG_RULE(2467-10, 2472+10, NL80211_NO_REG_BANDWIDTH_LIMIT,
+			 6, 20, NL80211_RRF_PASSIVE_SCAN |
+				NL80211_RRF_NO_IBSS),
 		/* IEEE 802.11 channel 14 - Only JP enables
 		 * this and for 802.11b only */
-		REG_RULE(2484-10, 2484+10, 20, 6, 20,
-			NL80211_RRF_PASSIVE_SCAN |
-			NL80211_RRF_NO_IBSS |
-			NL80211_RRF_NO_OFDM),
+		REG_RULE(2484-10, 2484+10, NL80211_NO_REG_BANDWIDTH_LIMIT,
+			 6, 20, NL80211_RRF_PASSIVE_SCAN |
+				NL80211_RRF_NO_IBSS |
+				NL80211_RRF_NO_OFDM),
 		/* IEEE 802.11a, channel 36..48 */
-		REG_RULE(5180-10, 5240+10, 40, 6, 20,
-                        NL80211_RRF_PASSIVE_SCAN |
-                        NL80211_RRF_NO_IBSS),
+		REG_RULE(5180-10, 5240+10, NL80211_NO_REG_BANDWIDTH_LIMIT,
+			 6, 20, NL80211_RRF_PASSIVE_SCAN |
+				NL80211_RRF_NO_IBSS),
 
 		/* NB: 5260 MHz - 5700 MHz requies DFS */
 
 		/* IEEE 802.11a, channel 149..165 */
-		REG_RULE(5745-10, 5825+10, 40, 6, 20,
-			NL80211_RRF_PASSIVE_SCAN |
-			NL80211_RRF_NO_IBSS),
+		REG_RULE(5745-10, 5825+10, NL80211_NO_REG_BANDWIDTH_LIMIT,
+			 6, 20, NL80211_RRF_PASSIVE_SCAN |
+				NL80211_RRF_NO_IBSS),
 
 		/* IEEE 802.11ad (60gHz), channels 1..3 */
 		REG_RULE(56160+2160*1-1080, 56160+2160*3+1080, 2160, 0, 0, 0),
@@ -482,8 +482,13 @@ static bool is_valid_reg_rule(const struct ieee80211_reg_rule *rule)
 
 	freq_diff = freq_range->end_freq_khz - freq_range->start_freq_khz;
 
-	if (freq_range->end_freq_khz <= freq_range->start_freq_khz ||
-	    freq_range->max_bandwidth_khz > freq_diff)
+	if (freq_range->end_freq_khz <= freq_range->start_freq_khz)
+		return false;
+
+	if (freq_range->max_bandwidth_khz == NL80211_NO_REG_BANDWIDTH_LIMIT)
+		return true;
+
+	if (freq_range->max_bandwidth_khz > freq_diff)
 		return false;
 
 	return true;
@@ -588,7 +593,8 @@ static int reg_rules_intersect(const struct ieee80211_reg_rule *rule1,
 					    freq_range2->max_bandwidth_khz);
 
 	freq_diff = freq_range->end_freq_khz - freq_range->start_freq_khz;
-	if (freq_range->max_bandwidth_khz > freq_diff)
+	if (freq_range->max_bandwidth_khz != NL80211_NO_REG_BANDWIDTH_LIMIT &&
+	    freq_range->max_bandwidth_khz > freq_diff)
 		freq_range->max_bandwidth_khz = freq_diff;
 
 	power_rule->max_eirp = min(power_rule1->max_eirp,
@@ -806,7 +812,7 @@ static void chan_reg_rule_print_dbg(struct ieee80211_channel *chan,
 	REG_DBG_PRINT("Updating information on frequency %d MHz with regulatory rule:\n",
 		      chan->center_freq);
 
-	REG_DBG_PRINT("%d KHz - %d KHz @ %d KHz), (%s mBi, %d mBm)\n",
+	REG_DBG_PRINT("%d KHz - %d KHz @ %u KHz), (%s mBi, %d mBm)\n",
 		      freq_range->start_freq_khz, freq_range->end_freq_khz,
 		      freq_range->max_bandwidth_khz, max_antenna_gain,
 		      power_rule->max_eirp);
@@ -1971,27 +1977,26 @@ static void print_rd_rules(const struct ieee80211_regdomain *rd)
 	pr_info("  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)\n");
 
 	for (i = 0; i < rd->n_reg_rules; i++) {
+		char bandwidth[20] = "";
+		char max_ag[20] = "N/A";
+
 		reg_rule = &rd->reg_rules[i];
 		freq_range = &reg_rule->freq_range;
 		power_rule = &reg_rule->power_rule;
 
-		/*
-		 * There may not be documentation for max antenna gain
-		 * in certain regions
-		 */
+		if (freq_range->max_bandwidth_khz != NL80211_NO_REG_BANDWIDTH_LIMIT)
+			snprintf(bandwidth, sizeof(bandwidth),
+				 " @ %u KHz", freq_range->max_bandwidth_khz);
+
 		if (power_rule->max_antenna_gain)
-			pr_info("  (%d KHz - %d KHz @ %d KHz), (%d mBi, %d mBm)\n",
-				freq_range->start_freq_khz,
-				freq_range->end_freq_khz,
-				freq_range->max_bandwidth_khz,
-				power_rule->max_antenna_gain,
-				power_rule->max_eirp);
-		else
-			pr_info("  (%d KHz - %d KHz @ %d KHz), (N/A, %d mBm)\n",
-				freq_range->start_freq_khz,
-				freq_range->end_freq_khz,
-				freq_range->max_bandwidth_khz,
-				power_rule->max_eirp);
+			snprintf(max_ag, sizeof(max_ag),
+				 "%u mBi", power_rule->max_antenna_gain);
+
+		pr_info("  (%d KHz - %d KHz%s), (%s, %d mBm)\n",
+			freq_range->start_freq_khz,
+			freq_range->end_freq_khz,
+			bandwidth, max_ag,
+			power_rule->max_eirp);
 	}
 }
 
-- 
1.8.0

[RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

From: Johannes Berg <johannes.berg@intel.com>

Now that we can access the regulatory database without
holding locks, check the desired bandwidth against it
when a channel definition is checked. This addresses
the missing VHT bandwidth check, HT is already handled
by setting flags when the regdomain changes.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/wireless/chan.c | 12 +++++++++++-
 net/wireless/reg.c  | 37 ++++++++++++++++++++++++++++++-------
 net/wireless/reg.h  |  3 +++
 3 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index a7990bb..10b3475 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -10,6 +10,7 @@
 #include <net/cfg80211.h>
 #include "core.h"
 #include "rdev-ops.h"
+#include "reg.h"
 
 void cfg80211_chandef_create(struct cfg80211_chan_def *chandef,
 			     struct ieee80211_channel *chan,
@@ -201,6 +202,9 @@ static bool cfg80211_secondary_chans_ok(struct wiphy *wiphy,
 		c = ieee80211_get_channel(wiphy, freq);
 		if (!c || c->flags & prohibited_flags)
 			return false;
+		if (!reg_check_bandwidth(wiphy, MHZ_TO_KHZ(freq),
+					 MHZ_TO_KHZ(bandwidth)))
+			return false;
 	}
 
 	return true;
@@ -263,7 +267,13 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
 		return false;
 	}
 
-	/* TODO: missing regulatory check on 80/160 bandwidth */
+	/*
+	 * TODO: What if there are only certain 80/160/80+80 MHz channels
+	 *	 allowed by the driver, or only certain combinations?
+	 *	 For 40 MHz the driver can set the NO_HT40 flags, but for
+	 *	 80/160 MHz and in particular 80+80 MHz this isn't really
+	 *	 feasible -- should we ask the driver here?
+	 */
 
 	if (width > 20)
 		prohibited_flags |= IEEE80211_CHAN_NO_OFDM;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 422b93e..d57148d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -122,13 +122,15 @@ static inline void assert_reg_lock(void)
 static const struct ieee80211_regdomain *get_cfg80211_regdom(void)
 {
 	return rcu_dereference_protected(cfg80211_regdomain,
-					 lockdep_is_held(&reg_mutex));
+					 lockdep_is_held(&reg_mutex) ||
+					 rcu_read_lock_held());
 }
 
 static const struct ieee80211_regdomain *get_wiphy_regdom(struct wiphy *wiphy)
 {
 	return rcu_dereference_protected(wiphy->regd,
-					 lockdep_is_held(&reg_mutex));
+					 lockdep_is_held(&reg_mutex) ||
+					 rcu_read_lock_held());
 }
 
 static void rcu_free_regdom(const struct ieee80211_regdomain *r)
@@ -141,7 +143,8 @@ static void rcu_free_regdom(const struct ieee80211_regdomain *r)
 static struct regulatory_request *get_last_request(void)
 {
 	return rcu_dereference_protected(last_request,
-					 lockdep_is_held(&reg_mutex));
+					 lockdep_is_held(&reg_mutex) ||
+					 rcu_read_lock_held());
 }
 
 /* Used to queue up regulatory hints */
@@ -758,7 +761,7 @@ freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq,
 const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy,
 					       u32 center_freq)
 {
-	const struct ieee80211_regdomain *regd;
+	const struct ieee80211_regdomain *regd = NULL;
 	struct regulatory_request *lr = get_last_request();
 
 	/*
@@ -766,16 +769,36 @@ const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy,
 	 * IE has been processed or a user wants to help complaince further
 	 */
 	if (lr->initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE &&
-	    lr->initiator != NL80211_REGDOM_SET_BY_USER &&
-	    wiphy->regd)
+	    lr->initiator != NL80211_REGDOM_SET_BY_USER)
 		regd = get_wiphy_regdom(wiphy);
-	else
+
+	if (!regd)
 		regd = get_cfg80211_regdom();
 
 	return freq_reg_info_regd(wiphy, center_freq, regd);
 }
 EXPORT_SYMBOL(freq_reg_info);
 
+bool reg_check_bandwidth(struct wiphy *wiphy,
+			 u32 center_freq_khz, u32 bw_khz)
+{
+	const struct ieee80211_reg_rule *reg_rule;
+
+	/*
+	 * This interpretation is a bit of a strange quirk in the regulatory
+	 * rules definitions that we have today: each 20 MHz channel must fit
+	 * entirely into a single regulatory range, but if this range forbids
+	 * using more than 20 MHz then it forbids even using a small part of
+	 * this for the wider channel.
+	 */
+
+	reg_rule = freq_reg_info(wiphy, center_freq_khz);
+	if (!IS_ERR(reg_rule))
+		return reg_rule->freq_range.max_bandwidth_khz >= bw_khz;
+
+	return false;
+}
+
 #ifdef CONFIG_CFG80211_REG_DEBUG
 static const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
 {
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index af2d5f8..d6740ab 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -35,6 +35,9 @@ int set_regdom(const struct ieee80211_regdomain *rd);
 
 bool reg_last_request_cell_base(void);
 
+bool reg_check_bandwidth(struct wiphy *wiphy,
+			 u32 center_freq_khz, u32 bw_khz);
+
 /**
  * regulatory_hint_found_beacon - hints a beacon was found on a channel
  * @wiphy: the wireless device where the beacon was found on
-- 
1.8.0

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

On Thu, 2012-12-06 at 17:53 +0100, Johannes Berg wrote:

> +bool reg_check_bandwidth(struct wiphy *wiphy,
> +			 u32 center_freq_khz, u32 bw_khz)
> +{
> +	const struct ieee80211_reg_rule *reg_rule;
> +
> +	/*
> +	 * This interpretation is a bit of a strange quirk in the regulatory
> +	 * rules definitions that we have today: each 20 MHz channel must fit
> +	 * entirely into a single regulatory range, but if this range forbids
> +	 * using more than 20 MHz then it forbids even using a small part of
> +	 * this for the wider channel.
> +	 */
> +
> +	reg_rule = freq_reg_info(wiphy, center_freq_khz);
> +	if (!IS_ERR(reg_rule))
> +		return reg_rule->freq_range.max_bandwidth_khz >= bw_khz;

This needs rcu_read_lock() obviously... Fixed in my version in the wip
branch.

johannes

Re: [RFC 1/2] regulatory: allow arbitrary channel widths

[Luis R. Rodriguez]

On Thu, Dec 6, 2012 at 8:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There aren't any channel width restrictions in the
> 2.4 GHz band (except the natural ones by the (sub)band
> boundaries), nor do default restrictions in the 5 GHz
> band make sense when limited to passive scan/no IBSS
> etc.
>
> Allow passing NL80211_NO_REG_BANDWIDTH_LIMIT as the
> max_bandwidth_khz and make that mean no restrictions.
> Use it for the default world roaming regdomain.
>
> Also make the awk script accept "NL" for "no limit"
> and substitute NL80211_NO_REG_BANDWIDTH_LIMIT.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>

For 2.4 GHz this seems fine. For 5 GHz, just to clarify for Michael,
the changes you are making are for non-DFS channels, and for the
channels where we always never initiate radiation and just world roam
unless we get a beacon hint. That is the world regulatory domain
enabled 5 GHz channels that are non-DFS.

Michael, just a sanity check for you. What Johannes is saying is that
regulatory wise for the 2.4 GHz band on channels 1-11 and on 5 GHz on
non DFS channels where we never initiate radiation we don't have a
specific bandwidth restriction. Are you aware of any country
restricting any 5 GHz world roaming frequency (non DFS) or channel
1-11 on 2.4 GHz in terms of bandwidth used?

  Luis

Re: [RFC 1/2] regulatory: allow arbitrary channel widths

[Luis R. Rodriguez]

Oops, forgot to add Michael, adding him now.

Michael, just a sanity check for you. What Johannes is saying is that
regulatory wise for the 2.4 GHz band on channels 1-11 and on 5 GHz on
non DFS channels where we never initiate radiation we don't have a
specific bandwidth restriction. Are you aware of any country
restricting any 5 GHz world roaming frequency (non DFS) or channel
1-11 on 2.4 GHz in terms of bandwidth used?

  Luis

On Thu, Dec 13, 2012 at 2:27 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Thu, Dec 6, 2012 at 8:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> There aren't any channel width restrictions in the
>> 2.4 GHz band (except the natural ones by the (sub)band
>> boundaries), nor do default restrictions in the 5 GHz
>> band make sense when limited to passive scan/no IBSS
>> etc.
>>
>> Allow passing NL80211_NO_REG_BANDWIDTH_LIMIT as the
>> max_bandwidth_khz and make that mean no restrictions.
>> Use it for the default world roaming regdomain.
>>
>> Also make the awk script accept "NL" for "no limit"
>> and substitute NL80211_NO_REG_BANDWIDTH_LIMIT.
>>
>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>
> For 2.4 GHz this seems fine. For 5 GHz, just to clarify for Michael,
> the changes you are making are for non-DFS channels, and for the
> channels where we always never initiate radiation and just world roam
> unless we get a beacon hint. That is the world regulatory domain
> enabled 5 GHz channels that are non-DFS.
>
> Michael, just a sanity check for you. What Johannes is saying is that
> regulatory wise for the 2.4 GHz band on channels 1-11 and on 5 GHz on
> non DFS channels where we never initiate radiation we don't have a
> specific bandwidth restriction. Are you aware of any country
> restricting any 5 GHz world roaming frequency (non DFS) or channel
> 1-11 on 2.4 GHz in terms of bandwidth used?
>
>   Luis

Re: [RFC 1/2] regulatory: allow arbitrary channel widths

[Johannes Berg]

On Thu, 2012-12-13 at 14:28 -0800, Luis R. Rodriguez wrote:
> Oops, forgot to add Michael, adding him now.
> 
> Michael, just a sanity check for you. What Johannes is saying is that
> regulatory wise for the 2.4 GHz band on channels 1-11 and on 5 GHz on
> non DFS channels where we never initiate radiation we don't have a
> specific bandwidth restriction. Are you aware of any country
> restricting any 5 GHz world roaming frequency (non DFS) or channel
> 1-11 on 2.4 GHz in terms of bandwidth used?

This is world roaming, so we never use any of the 5 GHz channels unless
we've heard a beacon. If we hear beacons on consecutive (non-DFS)
channels (say 36,40,44,48) we would even enable them and then allow
using 80 MHz there. We could try to prevent this in some way I guess,
but it'd be more complex, and I'm not sure it's needed. However, I think
we need to be able to use 80 MHz in world roaming situations, which the
bandwidth setting currently prevents.

johannes

Re: [RFC 1/2] regulatory: allow arbitrary channel widths

[Johannes Berg]

On Thu, 2012-12-13 at 23:33 +0100, Johannes Berg wrote:
> On Thu, 2012-12-13 at 14:28 -0800, Luis R. Rodriguez wrote:
> > Oops, forgot to add Michael, adding him now.
> > 
> > Michael, just a sanity check for you. What Johannes is saying is that
> > regulatory wise for the 2.4 GHz band on channels 1-11 and on 5 GHz on
> > non DFS channels where we never initiate radiation we don't have a
> > specific bandwidth restriction. Are you aware of any country
> > restricting any 5 GHz world roaming frequency (non DFS) or channel
> > 1-11 on 2.4 GHz in terms of bandwidth used?
> 
> This is world roaming, so we never use any of the 5 GHz channels unless
> we've heard a beacon. If we hear beacons on consecutive (non-DFS)
> channels (say 36,40,44,48) we would even enable them and then allow
> using 80 MHz there. We could try to prevent this in some way I guess,
> but it'd be more complex, and I'm not sure it's needed. However, I think
> we need to be able to use 80 MHz in world roaming situations, which the
> bandwidth setting currently prevents.

Btw, soon enough I'll need to update the regdb for VHT, so if anyone has
any worldwide data on 80/160 MHz restrictions I'd love to know about it.

johannes

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Luis R. Rodriguez]

On Mon, Dec 10, 2012 at 9:06 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-12-06 at 17:53 +0100, Johannes Berg wrote:
>
>> +bool reg_check_bandwidth(struct wiphy *wiphy,
>> +                      u32 center_freq_khz, u32 bw_khz)
>> +{
>> +     const struct ieee80211_reg_rule *reg_rule;
>> +
>> +     /*
>> +      * This interpretation is a bit of a strange quirk in the regulatory
>> +      * rules definitions that we have today: each 20 MHz channel must fit
>> +      * entirely into a single regulatory range, but if this range forbids
>> +      * using more than 20 MHz then it forbids even using a small part of
>> +      * this for the wider channel.
>> +      */
>> +
>> +     reg_rule = freq_reg_info(wiphy, center_freq_khz);
>> +     if (!IS_ERR(reg_rule))
>> +             return reg_rule->freq_range.max_bandwidth_khz >= bw_khz;
>
> This needs rcu_read_lock() obviously... Fixed in my version in the wip
> branch.

Looks good, the get_wiphy_regdom() change above seemed like it'd
belong on a separate patch though.

  Luis

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Luis R. Rodriguez]

On Thu, Dec 6, 2012 at 8:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> -       /* TODO: missing regulatory check on 80/160 bandwidth */
> +       /*
> +        * TODO: What if there are only certain 80/160/80+80 MHz channels
> +        *       allowed by the driver, or only certain combinations?
> +        *       For 40 MHz the driver can set the NO_HT40 flags, but for
> +        *       80/160 MHz and in particular 80+80 MHz this isn't really
> +        *       feasible -- should we ask the driver here?
> +        */

It'd be real odd if a card could only do certain settings but at least
from what I was told the spec did limit the required combinations to a
smaller set so technically I could see the firmware having the checks
to only allow those settings. I don't think it makes sense to add this
as a limitation that gets annotated by a flag on the driver though. I
suspect we can assume a driver that supports VHT80 will support those
combos defined on the spec and so will a card that can support VHT160
and the only restriction really should be regulatory.

  Luis

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

On Thu, 2012-12-13 at 14:34 -0800, Luis R. Rodriguez wrote:
> On Mon, Dec 10, 2012 at 9:06 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Thu, 2012-12-06 at 17:53 +0100, Johannes Berg wrote:
> >
> >> +bool reg_check_bandwidth(struct wiphy *wiphy,
> >> +                      u32 center_freq_khz, u32 bw_khz)
> >> +{
> >> +     const struct ieee80211_reg_rule *reg_rule;
> >> +
> >> +     /*
> >> +      * This interpretation is a bit of a strange quirk in the regulatory
> >> +      * rules definitions that we have today: each 20 MHz channel must fit
> >> +      * entirely into a single regulatory range, but if this range forbids
> >> +      * using more than 20 MHz then it forbids even using a small part of
> >> +      * this for the wider channel.
> >> +      */
> >> +
> >> +     reg_rule = freq_reg_info(wiphy, center_freq_khz);
> >> +     if (!IS_ERR(reg_rule))
> >> +             return reg_rule->freq_range.max_bandwidth_khz >= bw_khz;
> >
> > This needs rcu_read_lock() obviously... Fixed in my version in the wip
> > branch.
> 
> Looks good, the get_wiphy_regdom() change above seemed like it'd
> belong on a separate patch though.

Humm, yeah, wtf. That belongs into the RCU change.

johannes

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

On Thu, 2012-12-13 at 14:38 -0800, Luis R. Rodriguez wrote:
> On Thu, Dec 6, 2012 at 8:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > -       /* TODO: missing regulatory check on 80/160 bandwidth */
> > +       /*
> > +        * TODO: What if there are only certain 80/160/80+80 MHz channels
> > +        *       allowed by the driver, or only certain combinations?
> > +        *       For 40 MHz the driver can set the NO_HT40 flags, but for
> > +        *       80/160 MHz and in particular 80+80 MHz this isn't really
> > +        *       feasible -- should we ask the driver here?
> > +        */
> 
> It'd be real odd if a card could only do certain settings but at least
> from what I was told the spec did limit the required combinations to a
> smaller set so technically I could see the firmware having the checks
> to only allow those settings. I don't think it makes sense to add this
> as a limitation that gets annotated by a flag on the driver though. I
> suspect we can assume a driver that supports VHT80 will support those
> combos defined on the spec and so will a card that can support VHT160
> and the only restriction really should be regulatory.

Ok so mostly I'm thinking 80+80 limitations. I could imagine, for
example, that a card doesn't want to do 80+80 if they're adjacent (do
160 instead), but I have no idea what 80+80 cards are like...

johannes

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Luis R. Rodriguez]

On Thu, Dec 13, 2012 at 2:47 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-12-13 at 14:38 -0800, Luis R. Rodriguez wrote:
>> On Thu, Dec 6, 2012 at 8:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > -       /* TODO: missing regulatory check on 80/160 bandwidth */
>> > +       /*
>> > +        * TODO: What if there are only certain 80/160/80+80 MHz channels
>> > +        *       allowed by the driver, or only certain combinations?
>> > +        *       For 40 MHz the driver can set the NO_HT40 flags, but for
>> > +        *       80/160 MHz and in particular 80+80 MHz this isn't really
>> > +        *       feasible -- should we ask the driver here?
>> > +        */
>>
>> It'd be real odd if a card could only do certain settings but at least
>> from what I was told the spec did limit the required combinations to a
>> smaller set so technically I could see the firmware having the checks
>> to only allow those settings. I don't think it makes sense to add this
>> as a limitation that gets annotated by a flag on the driver though. I
>> suspect we can assume a driver that supports VHT80 will support those
>> combos defined on the spec and so will a card that can support VHT160
>> and the only restriction really should be regulatory.
>
> Ok so mostly I'm thinking 80+80 limitations. I could imagine, for
> example, that a card doesn't want to do 80+80 if they're adjacent (do
> 160 instead), but I have no idea what 80+80 cards are like...

Pfft, yeah I have no clue yet. Felix would you know if there are any
limitations hardware wise in theory at least of doing 80+80
configurations (apart form what the standard would allow).

  Luis

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

On Thu, 2012-12-13 at 23:46 +0100, Johannes Berg wrote:
> On Thu, 2012-12-13 at 14:34 -0800, Luis R. Rodriguez wrote:
> > On Mon, Dec 10, 2012 at 9:06 AM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> > > On Thu, 2012-12-06 at 17:53 +0100, Johannes Berg wrote:
> > >
> > >> +bool reg_check_bandwidth(struct wiphy *wiphy,
> > >> +                      u32 center_freq_khz, u32 bw_khz)
> > >> +{
> > >> +     const struct ieee80211_reg_rule *reg_rule;
> > >> +
> > >> +     /*
> > >> +      * This interpretation is a bit of a strange quirk in the regulatory
> > >> +      * rules definitions that we have today: each 20 MHz channel must fit
> > >> +      * entirely into a single regulatory range, but if this range forbids
> > >> +      * using more than 20 MHz then it forbids even using a small part of
> > >> +      * this for the wider channel.
> > >> +      */
> > >> +
> > >> +     reg_rule = freq_reg_info(wiphy, center_freq_khz);
> > >> +     if (!IS_ERR(reg_rule))
> > >> +             return reg_rule->freq_range.max_bandwidth_khz >= bw_khz;
> > >
> > > This needs rcu_read_lock() obviously... Fixed in my version in the wip
> > > branch.
> > 
> > Looks good, the get_wiphy_regdom() change above seemed like it'd
> > belong on a separate patch though.
> 
> Humm, yeah, wtf. That belongs into the RCU change.

No actually it doesn't, though I could make it a separate patch with the
reg.c changes except for adding reg_check_bandwidth(), but that'd only
be something like "prepare to be able to use rcu protection for
freq_reg_info", I think I'll keep it this way but add some description.

johannes

RE: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Bitterli, Felix]

________________________________________
From: mcgrof@gmail.com [mcgrof@gmail.com] on behalf of Luis R. Rodriguez [mcgrof@do-not-panic.com]
Sent: Thursday, December 13, 2012 2:49 PM
To: Johannes Berg; Bitterli, Felix
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

On Thu, Dec 13, 2012 at 2:47 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-12-13 at 14:38 -0800, Luis R. Rodriguez wrote:
>> On Thu, Dec 6, 2012 at 8:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > -       /* TODO: missing regulatory check on 80/160 bandwidth */
>> > +       /*
>> > +        * TODO: What if there are only certain 80/160/80+80 MHz channels
>> > +        *       allowed by the driver, or only certain combinations?
>> > +        *       For 40 MHz the driver can set the NO_HT40 flags, but for
>> > +        *       80/160 MHz and in particular 80+80 MHz this isn't really
>> > +        *       feasible -- should we ask the driver here?
>> > +        */
>>
>> It'd be real odd if a card could only do certain settings but at least
>> from what I was told the spec did limit the required combinations to a
>> smaller set so technically I could see the firmware having the checks
>> to only allow those settings. I don't think it makes sense to add this
>> as a limitation that gets annotated by a flag on the driver though. I
>> suspect we can assume a driver that supports VHT80 will support those
>> combos defined on the spec and so will a card that can support VHT160
>> and the only restriction really should be regulatory.
>
> Ok so mostly I'm thinking 80+80 limitations. I could imagine, for
> example, that a card doesn't want to do 80+80 if they're adjacent (do
> 160 instead), but I have no idea what 80+80 cards are like...

Pfft, yeah I have no clue yet. Felix would you know if there are any
limitations hardware wise in theory at least of doing 80+80
configurations (apart form what the standard would allow).

  Luis

[Felix:] Firstly, overlapping 40M channels are not allowed, overlapping 80M channels are not allowed, same for 160M. So each individual 80 of the 80+80 has to follow previous rule. In case the two 80 are adjacent, it's called 160.

  Best regards, Felix (apologies for owa quoting improperly)

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

On Fri, 2012-12-14 at 00:12 +0100, Johannes Berg wrote:

> > > Looks good, the get_wiphy_regdom() change above seemed like it'd
> > > belong on a separate patch though.
> > 
> > Humm, yeah, wtf. That belongs into the RCU change.
> 
> No actually it doesn't, though I could make it a separate patch with the
> reg.c changes except for adding reg_check_bandwidth(), but that'd only
> be something like "prepare to be able to use rcu protection for
> freq_reg_info", I think I'll keep it this way but add some description.

Added this:

    To do this modify freq_reg_info() to be callable with
    RCU protection and use that, acquiring the mutex isn't
    possible for this function.

johannes

Re: [RFC 2/2] cfg80211: check (VHT) bandwidth against regulatory

[Johannes Berg]

On Thu, 2012-12-13 at 23:13 +0000, Bitterli, Felix wrote:

> Pfft, yeah I have no clue yet. Felix would you know if there are any
> limitations hardware wise in theory at least of doing 80+80
> configurations (apart form what the standard would allow).

>  In case the two 80 are adjacent, it's called 160.

So basically you're saying in general, 80+80 adjacent aren't allowed.
I'll put in a check for that.

johannes