[PATCH 0/8] wireless: add DFS master support

[PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

This set of 8 patches adds DFS master support to the Linux wireless subsystem.
I've reviewed future possible changes to DFS master regions and it seems that
we are not going to be having multiple DFS regions for one country, instead
we'll always have one DFS region for one country.

The changes here are spread out throughout wireless-regdb, crda the kernel and
lastly iw. The changes made allow for older verions of CRDA to work with new
wireless-regdb files with DFS region support. If you want DFS master region
support you'll need to upgrade your CRDA, your kernel and then hope someone
implements DFS master support for your respective driver.

This patch series does not have specific driver changes, although some seem to
be backing in the oven right now.

Luis R. Rodriguez (8):
  wireless-regdb: Add master DFS region support
  wireless-regdb: add FCC as the DFS region for US
  crda: synch up nl80211.h
  crda: add support to send DFS master region
  cfg80211: process regulatory DFS region for countries
  cfg80211: pass DFS region to drivers through reg_notifier()
  iw: synch nl80211.h
  iw: add DFS region parsing support

wireless-regdb:

 db.txt     |    2 +-
 db2bin.py  |    2 +-
 dbparse.py |   25 ++++++++++++++++++++-----
 3 files changed, 22 insertions(+), 7 deletions(-)

crda:

 crda.c    |    1 +
 nl80211.h |   21 +++++++++++++++++++++
 regdb.h   |    3 ++-
 3 files changed, 24 insertions(+), 1 deletions(-)

kernel:

 include/linux/nl80211.h  |   21 +++++++++++++++++++++
 include/net/regulatory.h |    6 ++++++
 net/wireless/nl80211.c   |   15 +++++++++++++++
 net/wireless/reg.c       |   39 +++++++++++++++++++++++++++++++++++++++
 net/wireless/reg.h       |    1 +
 5 files changed, 82 insertions(+), 0 deletions(-)

iw:

 nl80211.h |  168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 reg.c     |   31 +++++++++++
 2 files changed, 197 insertions(+), 2 deletions(-)

-- 
1.7.4.15.g7811d

[PATCH 1/8] wireless-regdb: Add master DFS region support

[Luis R. Rodriguez]

To support master DFS we add the three known DFS regions which
countries are known to support. In order to modify the regulatory
database schema in a backward compatible way we use one of
the two pad bytes which were unused. By using one of the two pad
bytes we end up keeping new regulatory databases with DFS region
support compatible with older verions of CRDA, the DFS region would
just not be sent to the kernel.

DFS master is only required for modes of operation which iniate
radiation on DFS channels, we will start supporting DFS with AP
mode of operation. Without DFS master support you cannot intiate
radiation on those channels (AP, Mesh, IBSS, P2P). Apart from support
from wireless-regdb, crda and the 802.11 stack you'll also need proper
DFS support on your device driver to use this.

A country can only map to one DFS region at a time for all frequency
regions. After this patch countries can start being mapped to their
own DFS region.

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 db2bin.py  |    2 +-
 dbparse.py |   25 ++++++++++++++++++++-----
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/db2bin.py b/db2bin.py
index 23d3ee2..41d3741 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -116,7 +116,7 @@ countrynames.sort()
 for alpha2 in countrynames:
     coll = countries[alpha2]
     # struct regdb_file_reg_country
-    output.write(struct.pack('>ccxxI', str(alpha2[0]), str(alpha2[1]), reg_rules_collections[coll.permissions]))
+    output.write(struct.pack('>ccxBI', str(alpha2[0]), str(alpha2[1]), coll.dfs_region, reg_rules_collections[coll.permissions]))
 
 
 if len(sys.argv) > 3:
diff --git a/dbparse.py b/dbparse.py
index 2c0d738..893d64e 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -18,6 +18,12 @@ flag_definitions = {
     'NO-HT40':		1<<10,
 }
 
+dfs_regions = {
+    'DFS-FCC':		1,
+    'DFS-ETSI':		2,
+    'DFS-JP':		3,
+}
+
 class FreqBand(object):
     def __init__(self, start, end, bw, comments=None):
         self.start = start
@@ -61,6 +67,10 @@ class PowerRestriction(object):
         s = self
         return hash((s.max_ant_gain, s.max_eirp))
 
+class DFSRegionError(Exception):
+    def __init__(self, dfs_region):
+        self.dfs_region = dfs_region
+
 class FlagError(Exception):
     def __init__(self, flag):
         self.flag = flag
@@ -90,9 +100,15 @@ class Permission(object):
         return hash(self._as_tuple())
 
 class Country(object):
-    def __init__(self, permissions=None, comments=None):
+    def __init__(self, dfs_region, permissions=None, comments=None):
         self._permissions = permissions or []
         self.comments = comments or []
+	self.dfs_region = 0
+
+	if dfs_region:
+		if not dfs_region in dfs_regions:
+		    raise DFSRegionError(dfs_region)
+		self.dfs_region = dfs_regions[dfs_region]
 
     def add(self, perm):
         assert isinstance(perm, Permission)
@@ -224,11 +240,10 @@ class DBParser(object):
 
     def _parse_country(self, line):
         try:
-            cname, line = line.split(':', 1)
+            cname, cvals= line.split(':', 1)
+            dfs_region = cvals.strip()
             if not cname:
                 self._syntax_error("'country' keyword must be followed by name")
-            if line:
-                self._syntax_error("extra data at end of country line")
         except ValueError:
             self._syntax_error("country name must be followed by colon")
 
@@ -239,7 +254,7 @@ class DBParser(object):
             if len(cname) != 2:
                 self._warn("country '%s' not alpha2" % cname)
             if not cname in self._countries:
-                self._countries[cname] = Country(comments=self._comments)
+                self._countries[cname] = Country(dfs_region, comments=self._comments)
             self._current_countries[cname] = self._countries[cname]
         self._comments = []
 
-- 
1.7.4.15.g7811d

[PATCH 2/8] wireless-regdb: add FCC as the DFS region for US

[Luis R. Rodriguez]

DFS master support in the US requires consideration for DFS
requirements as defined by the FCC rules.

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 db.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/db.txt b/db.txt
index f0b46d8..4b7e879 100644
--- a/db.txt
+++ b/db.txt
@@ -651,7 +651,7 @@ country TR:
 country UA:
 	(2402 - 2482 @ 40), (N/A, 20)
 
-country US:
+country US: DFS-FCC
 	(2402 - 2472 @ 40), (3, 27)
 	(5170 - 5250 @ 40), (3, 17)
 	(5250 - 5330 @ 40), (3, 20), DFS
-- 
1.7.4.15.g7811d

[PATCH 3/8] cfg80211: process regulatory DFS region for countries

[Luis R. Rodriguez]

The wireless-regdb now has support for mapping a country to
one DFS region. CRDA sends this to us now so process it
so we can provide that hint to drivers. This will later be
used by code for processing DFS in a way that meets the
criteria for the DFS region the country belongs to.

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 include/linux/nl80211.h  |   21 +++++++++++++++++++++
 include/net/regulatory.h |    1 +
 net/wireless/nl80211.c   |   15 +++++++++++++++
 net/wireless/reg.c       |   37 +++++++++++++++++++++++++++++++++++++
 net/wireless/reg.h       |    1 +
 5 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 9d797f2..3d7f468 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -1109,6 +1109,10 @@ enum nl80211_commands {
  *	%NL80211_CMD_TDLS_MGMT. Otherwise %NL80211_CMD_TDLS_OPER should be
  *	used for asking the driver to perform a TDLS operation.
  *
+ * @NL80211_ATTR_DFS_REGION: region for regulatory rules which this country
+ *    abides to when initiating radiation on DFS channels. A country maps
+ *    to one DFS region.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -1337,6 +1341,8 @@ enum nl80211_attrs {
 	NL80211_ATTR_TDLS_SUPPORT,
 	NL80211_ATTR_TDLS_EXTERNAL_SETUP,
 
+	NL80211_ATTR_DFS_REGION,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
@@ -1843,6 +1849,21 @@ enum nl80211_reg_rule_flags {
 };
 
 /**
+ * enum nl80211_dfs_regions - regulatory DFS regions
+ *
+ * @NL80211_DFS_UNSET: Country has no DFS master region specified
+ * @NL80211_DFS_FCC_: Country follows DFS master rules from FCC
+ * @NL80211_DFS_FCC_: Country follows DFS master rules from ETSI
+ * @NL80211_DFS_JP_: Country follows DFS master rules from JP/MKK/Telec
+ */
+enum nl80211_cflags {
+	NL80211_DFS_UNSET	= 0,
+	NL80211_DFS_FCC		= 1,
+	NL80211_DFS_ETSI	= 2,
+	NL80211_DFS_JP		= 3,
+};
+
+/**
  * enum nl80211_survey_info - survey information
  *
  * These attribute types are used with %NL80211_ATTR_SURVEY_INFO
diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index eb7d3c2..7399c93 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -93,6 +93,7 @@ struct ieee80211_reg_rule {
 struct ieee80211_regdomain {
 	u32 n_reg_rules;
 	char alpha2[2];
+	u8 dfs_region;
 	struct ieee80211_reg_rule reg_rules[];
 };
 
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index edf655a..8d3012a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -197,6 +197,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
 	[NL80211_ATTR_TDLS_OPERATION] = { .type = NLA_U8 },
 	[NL80211_ATTR_TDLS_SUPPORT] = { .type = NLA_FLAG },
 	[NL80211_ATTR_TDLS_EXTERNAL_SETUP] = { .type = NLA_FLAG },
+	[NL80211_ATTR_DFS_REGION] = { .type = NLA_U8 },
 };
 
 /* policy for the key attributes */
@@ -3348,6 +3349,9 @@ static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
 
 	NLA_PUT_STRING(msg, NL80211_ATTR_REG_ALPHA2,
 		cfg80211_regdomain->alpha2);
+	if (cfg80211_regdomain->dfs_region)
+		NLA_PUT_U8(msg, NL80211_ATTR_DFS_REGION,
+			   cfg80211_regdomain->dfs_region);
 
 	nl_reg_rules = nla_nest_start(msg, NL80211_ATTR_REG_RULES);
 	if (!nl_reg_rules)
@@ -3406,6 +3410,7 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
 	char *alpha2 = NULL;
 	int rem_reg_rules = 0, r = 0;
 	u32 num_rules = 0, rule_idx = 0, size_of_regd;
+	u8 dfs_region = 0;
 	struct ieee80211_regdomain *rd = NULL;
 
 	if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
@@ -3416,6 +3421,9 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
 
 	alpha2 = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
 
+	if (info->attrs[NL80211_ATTR_DFS_REGION])
+		dfs_region = nla_get_u8(info->attrs[NL80211_ATTR_DFS_REGION]);
+
 	nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
 			rem_reg_rules) {
 		num_rules++;
@@ -3443,6 +3451,13 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
 	rd->alpha2[0] = alpha2[0];
 	rd->alpha2[1] = alpha2[1];
 
+	/*
+	 * Disable DFS master mode if the DFS region was
+	 * not supported or known on this kernel.
+	 */
+	if (reg_supported_dfs_region(dfs_region))
+		rd->dfs_region = dfs_region;
+
 	nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
 			rem_reg_rules) {
 		nla_parse(tb, NL80211_REG_RULE_ATTR_MAX,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2520a1b..69141ed 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1946,6 +1946,42 @@ static void print_rd_rules(const struct ieee80211_regdomain *rd)
 	}
 }
 
+bool reg_supported_dfs_region(u8 dfs_region)
+{
+	switch (dfs_region) {
+	case NL80211_DFS_UNSET:
+	case NL80211_DFS_FCC:
+	case NL80211_DFS_ETSI:
+	case NL80211_DFS_JP:
+		return true;
+	default:
+		REG_DBG_PRINT("Ignoring uknown DFS master region: %d\n",
+			      dfs_region);
+		return false;
+	}
+}
+
+static void print_dfs_region(u8 dfs_region)
+{
+	if (!dfs_region)
+		return;
+
+	switch (dfs_region) {
+	case NL80211_DFS_FCC:
+		pr_info(" DFS Master region FCC");
+		break;
+	case NL80211_DFS_ETSI:
+		pr_info(" DFS Master region ETSI");
+		break;
+	case NL80211_DFS_JP:
+		pr_info(" DFS Master region JP");
+		break;
+	default:
+		pr_info(" DFS Master region Uknown");
+		break;
+	}
+}
+
 static void print_regdomain(const struct ieee80211_regdomain *rd)
 {
 
@@ -1973,6 +2009,7 @@ static void print_regdomain(const struct ieee80211_regdomain *rd)
 			pr_info("Regulatory domain changed to country: %c%c\n",
 				rd->alpha2[0], rd->alpha2[1]);
 	}
+	print_dfs_region(rd->dfs_region);
 	print_rd_rules(rd);
 }
 
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index 4a56799..786e414 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -5,6 +5,7 @@ extern const struct ieee80211_regdomain *cfg80211_regdomain;
 
 bool is_world_regdom(const char *alpha2);
 bool reg_is_valid_request(const char *alpha2);
+bool reg_supported_dfs_region(u8 dfs_region);
 
 int regulatory_hint_user(const char *alpha2);
 
-- 
1.7.4.15.g7811d

Re: [PATCH 3/8] cfg80211: process regulatory DFS region for countries

[Johannes Berg]

On Tue, 2011-10-04 at 16:47 -0700, Luis R. Rodriguez wrote:

>  /**
> + * enum nl80211_dfs_regions - regulatory DFS regions
> + *
> + * @NL80211_DFS_UNSET: Country has no DFS master region specified
> + * @NL80211_DFS_FCC_: Country follows DFS master rules from FCC
> + * @NL80211_DFS_FCC_: Country follows DFS master rules from ETSI
> + * @NL80211_DFS_JP_: Country follows DFS master rules from JP/MKK/Telec
> + */
> +enum nl80211_cflags {
> +	NL80211_DFS_UNSET	= 0,

That seems odd -- nl80211 convention would be to just leave out the
attribute.

johannes

Re: [PATCH 3/8] cfg80211: process regulatory DFS region for countries

[Luis R. Rodriguez]

On Fri, Oct 7, 2011 at 12:54 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2011-10-04 at 16:47 -0700, Luis R. Rodriguez wrote:
>
>>  /**
>> + * enum nl80211_dfs_regions - regulatory DFS regions
>> + *
>> + * @NL80211_DFS_UNSET: Country has no DFS master region specified
>> + * @NL80211_DFS_FCC_: Country follows DFS master rules from FCC
>> + * @NL80211_DFS_FCC_: Country follows DFS master rules from ETSI
>> + * @NL80211_DFS_JP_: Country follows DFS master rules from JP/MKK/Telec
>> + */
>> +enum nl80211_cflags {
>> +     NL80211_DFS_UNSET       = 0,
>
> That seems odd -- nl80211 convention would be to just leave out the
> attribute.

I wonder what seems more odd, having that present or looking at this:

+bool reg_supported_dfs_region(u8 dfs_region)
+{
+       switch (dfs_region) {
+       case 0:
+       case NL80211_DFS_FCC:
+       case NL80211_DFS_ETSI:
+       case NL80211_DFS_JP:
+               return true;
+       default:
+               REG_DBG_PRINT("Ignoring uknown DFS master region: %d\n",
+                             dfs_region);
+               return false;
+       }
+}

Vs:

+bool reg_supported_dfs_region(u8 dfs_region)
+{
+       switch (dfs_region) {
+       case NL80211_DFS_UNSET:
+       case NL80211_DFS_FCC:
+       case NL80211_DFS_ETSI:
+       case NL80211_DFS_JP:
+               return true;
+       default:
+               REG_DBG_PRINT("Ignoring uknown DFS master region: %d\n",
+                             dfs_region);
+               return false;
+       }
+}

You pick, you're the maintainer.

  Luis

Re: [PATCH 3/8] cfg80211: process regulatory DFS region for countries

[Johannes Berg]

On Fri, 2011-10-07 at 12:57 -0700, Luis R. Rodriguez wrote:
> On Fri, Oct 7, 2011 at 12:54 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Tue, 2011-10-04 at 16:47 -0700, Luis R. Rodriguez wrote:
> >
> >>  /**
> >> + * enum nl80211_dfs_regions - regulatory DFS regions
> >> + *
> >> + * @NL80211_DFS_UNSET: Country has no DFS master region specified
> >> + * @NL80211_DFS_FCC_: Country follows DFS master rules from FCC
> >> + * @NL80211_DFS_FCC_: Country follows DFS master rules from ETSI
> >> + * @NL80211_DFS_JP_: Country follows DFS master rules from JP/MKK/Telec
> >> + */
> >> +enum nl80211_cflags {
> >> +     NL80211_DFS_UNSET       = 0,
> >
> > That seems odd -- nl80211 convention would be to just leave out the
> > attribute.
> 
> I wonder what seems more odd, having that present or looking at this:
> 
> +bool reg_supported_dfs_region(u8 dfs_region)
> +{
> +       switch (dfs_region) {
> +       case 0:

Yeah I noticed later you were going to use that value internally as
well, guess it's fine.

johannes

[PATCH 4/8] cfg80211: pass DFS region to drivers through reg_notifier()

[Luis R. Rodriguez]

This grants drivers access to the DFS region that a
regulatory domain belongs to.

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 include/net/regulatory.h |    5 +++++
 net/wireless/reg.c       |    2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index 7399c93..a5f7993 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -48,6 +48,10 @@ enum environment_cap {
  * 	99 - built by driver but a specific alpha2 cannot be determined
  * 	98 - result of an intersection between two regulatory domains
  *	97 - regulatory domain has not yet been configured
+ * @dfs_region: If CRDA responded with a regulatory domain that requires
+ *	DFS master operation on a known DFS region (NL80211_DFS_*),
+ *	dfs_region represents that region. Drivers can use this and the
+ *	@alpha2 to adjust their device's DFS parameters as required.
  * @intersect: indicates whether the wireless core should intersect
  * 	the requested regulatory domain with the presently set regulatory
  * 	domain.
@@ -67,6 +71,7 @@ struct regulatory_request {
 	int wiphy_idx;
 	enum nl80211_reg_initiator initiator;
 	char alpha2[2];
+	u8 dfs_region;
 	bool intersect;
 	bool processed;
 	enum environment_cap country_ie_env;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 69141ed..b66444d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1121,6 +1121,8 @@ static void wiphy_update_regulatory(struct wiphy *wiphy,
 	if (ignore_reg_update(wiphy, initiator))
 		return;
 
+	last_request->dfs_region = cfg80211_regdomain->dfs_region;
+
 	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
 		if (wiphy->bands[band])
 			handle_band(wiphy, band, initiator);
-- 
1.7.4.15.g7811d

[PATCH 5/8] crda: synch up nl80211.h

[Luis R. Rodriguez]

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 nl80211.h |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/nl80211.h b/nl80211.h
index 9d797f2..3d7f468 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -1109,6 +1109,10 @@ enum nl80211_commands {
  *	%NL80211_CMD_TDLS_MGMT. Otherwise %NL80211_CMD_TDLS_OPER should be
  *	used for asking the driver to perform a TDLS operation.
  *
+ * @NL80211_ATTR_DFS_REGION: region for regulatory rules which this country
+ *    abides to when initiating radiation on DFS channels. A country maps
+ *    to one DFS region.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -1337,6 +1341,8 @@ enum nl80211_attrs {
 	NL80211_ATTR_TDLS_SUPPORT,
 	NL80211_ATTR_TDLS_EXTERNAL_SETUP,
 
+	NL80211_ATTR_DFS_REGION,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
@@ -1843,6 +1849,21 @@ enum nl80211_reg_rule_flags {
 };
 
 /**
+ * enum nl80211_dfs_regions - regulatory DFS regions
+ *
+ * @NL80211_DFS_UNSET: Country has no DFS master region specified
+ * @NL80211_DFS_FCC_: Country follows DFS master rules from FCC
+ * @NL80211_DFS_FCC_: Country follows DFS master rules from ETSI
+ * @NL80211_DFS_JP_: Country follows DFS master rules from JP/MKK/Telec
+ */
+enum nl80211_cflags {
+	NL80211_DFS_UNSET	= 0,
+	NL80211_DFS_FCC		= 1,
+	NL80211_DFS_ETSI	= 2,
+	NL80211_DFS_JP		= 3,
+};
+
+/**
  * enum nl80211_survey_info - survey information
  *
  * These attribute types are used with %NL80211_ATTR_SURVEY_INFO
-- 
1.7.4.15.g7811d

[PATCH 6/8] crda: add support to send DFS master region

[Luis R. Rodriguez]

wireless-regdb now has support for a DFS master region
for each country. We must read this from the file and
send it as an NL80211_ATTR_DFS_REGION attribute.

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 crda.c  |    1 +
 regdb.h |    3 ++-
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/crda.c b/crda.c
index 6857e3f..dfc5353 100644
--- a/crda.c
+++ b/crda.c
@@ -280,6 +280,7 @@ int main(int argc, char **argv)
 				country->reg_collection_ptr);
 
 	NLA_PUT_STRING(msg, NL80211_ATTR_REG_ALPHA2, (char *) country->alpha2);
+	NLA_PUT_U8(msg, NL80211_ATTR_DFS_REGION, country->dfs_region);
 
 	nl_reg_rules = nla_nest_start(msg, NL80211_ATTR_REG_RULES);
 	if (!nl_reg_rules) {
diff --git a/regdb.h b/regdb.h
index 045a0e3..b59115f 100644
--- a/regdb.h
+++ b/regdb.h
@@ -96,7 +96,8 @@ struct regdb_file_reg_rules_collection {
 
 struct regdb_file_reg_country {
 	__u8	alpha2[2];
-	__u8	PAD[2];
+	__u8	PAD;
+	__u8	dfs_region;
 	/* pointer (offset) into the file to a struct
 	 * regdb_file_reg_rules_collection */
 	__be32	reg_collection_ptr;
-- 
1.7.4.15.g7811d

[PATCH 7/8] iw: synch nl80211.h

[Luis R. Rodriguez]

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 nl80211.h |  168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 166 insertions(+), 2 deletions(-)

diff --git a/nl80211.h b/nl80211.h
index 0343504..3d7f468 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -238,6 +238,8 @@
  *
  * @NL80211_CMD_GET_SCAN: get scan results
  * @NL80211_CMD_TRIGGER_SCAN: trigger a new scan with the given parameters
+ *	%NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the
+ *	probe requests at CCK rate or not.
  * @NL80211_CMD_NEW_SCAN_RESULTS: scan notification (as a reply to
  *	NL80211_CMD_GET_SCAN and on the "scan" multicast group)
  * @NL80211_CMD_SCAN_ABORTED: scan was aborted, for unspecified reasons,
@@ -432,6 +434,8 @@
  *	specified using %NL80211_ATTR_DURATION. When called, this operation
  *	returns a cookie (%NL80211_ATTR_COOKIE) that will be included with the
  *	TX status event pertaining to the TX request.
+ *	%NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the
+ *	management frames at CCK rate or not in 2GHz band.
  * @NL80211_CMD_FRAME_WAIT_CANCEL: When an off-channel TX was requested, this
  *	command may be used with the corresponding cookie to cancel the wait
  *	time if it is known that it is no longer necessary.
@@ -499,6 +503,12 @@
  *	this command may also be sent by the driver as an MLME event to
  *	inform userspace of the new replay counter.
  *
+ * @NL80211_CMD_PMKSA_CANDIDATE: This is used as an event to inform userspace
+ *	of PMKSA caching dandidates.
+ *
+ * @NL80211_CMD_TDLS_OPER: Perform a high-level TDLS command (e.g. link setup).
+ * @NL80211_CMD_TDLS_MGMT: Send a TDLS management frame.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -623,6 +633,11 @@ enum nl80211_commands {
 
 	NL80211_CMD_SET_REKEY_OFFLOAD,
 
+	NL80211_CMD_PMKSA_CANDIDATE,
+
+	NL80211_CMD_TDLS_OPER,
+	NL80211_CMD_TDLS_MGMT,
+
 	/* add new commands above here */
 
 	/* used to define NL80211_CMD_MAX below */
@@ -769,6 +784,8 @@ enum nl80211_commands {
  *	that can be added to a scan request
  * @NL80211_ATTR_MAX_SCHED_SCAN_IE_LEN: maximum length of information
  *	elements that can be added to a scheduled scan request
+ * @NL80211_ATTR_MAX_MATCH_SETS: maximum number of sets that can be
+ *	used with @NL80211_ATTR_SCHED_SCAN_MATCH, a wiphy attribute.
  *
  * @NL80211_ATTR_SCAN_FREQUENCIES: nested attribute with frequencies (in MHz)
  * @NL80211_ATTR_SCAN_SSIDS: nested attribute with SSIDs, leave out for passive
@@ -1011,6 +1028,24 @@ enum nl80211_commands {
 
  * @NL80211_ATTR_SCHED_SCAN_INTERVAL: Interval between scheduled scan
  *	cycles, in msecs.
+
+ * @NL80211_ATTR_SCHED_SCAN_MATCH: Nested attribute with one or more
+ *	sets of attributes to match during scheduled scans.  Only BSSs
+ *	that match any of the sets will be reported.  These are
+ *	pass-thru filter rules.
+ *	For a match to succeed, the BSS must match all attributes of a
+ *	set.  Since not every hardware supports matching all types of
+ *	attributes, there is no guarantee that the reported BSSs are
+ *	fully complying with the match sets and userspace needs to be
+ *	able to ignore them by itself.
+ *	Thus, the implementation is somewhat hardware-dependent, but
+ *	this is only an optimization and the userspace application
+ *	needs to handle all the non-filtered results anyway.
+ *	If the match attributes don't make sense when combined with
+ *	the values passed in @NL80211_ATTR_SCAN_SSIDS (eg. if an SSID
+ *	is included in the probe request, but the match attributes
+ *	will never let it go through), -EINVAL may be returned.
+ *	If ommited, no filtering is done.
  *
  * @NL80211_ATTR_INTERFACE_COMBINATIONS: Nested attribute listing the supported
  *	interface combinations. In each nested item, it contains attributes
@@ -1044,6 +1079,39 @@ enum nl80211_commands {
  *
  * @NL80211_ATTR_STA_WME: Nested attribute containing the wme configuration
  *	of the station, see &enum nl80211_sta_wme_attr.
+ * @NL80211_ATTR_SUPPORT_AP_UAPSD: the device supports uapsd when working
+ *	as AP.
+ *
+ * @NL80211_ATTR_ROAM_SUPPORT: Indicates whether the firmware is capable of
+ *	roaming to another AP in the same ESS if the signal lever is low.
+ *
+ * @NL80211_ATTR_PMKSA_CANDIDATE: Nested attribute containing the PMKSA caching
+ *	candidate information, see &enum nl80211_pmksa_candidate_attr.
+ *
+ * @NL80211_ATTR_TX_NO_CCK_RATE: Indicates whether to use CCK rate or not
+ *	for management frames transmission. In order to avoid p2p probe/action
+ *	frames are being transmitted at CCK rate in 2GHz band, the user space
+ *	applications use this attribute.
+ *	This attribute is used with %NL80211_CMD_TRIGGER_SCAN and
+ *	%NL80211_CMD_FRAME commands.
+ *
+ * @NL80211_ATTR_TDLS_ACTION: Low level TDLS action code (e.g. link setup
+ *	request, link setup confirm, link teardown, etc.). Values are
+ *	described in the TDLS (802.11z) specification.
+ * @NL80211_ATTR_TDLS_DIALOG_TOKEN: Non-zero token for uniquely identifying a
+ *	TDLS conversation between two devices.
+ * @NL80211_ATTR_TDLS_OPERATION: High level TDLS operation; see
+ *	&enum nl80211_tdls_operation, represented as a u8.
+ * @NL80211_ATTR_TDLS_SUPPORT: A flag indicating the device can operate
+ *	as a TDLS peer sta.
+ * @NL80211_ATTR_TDLS_EXTERNAL_SETUP: The TDLS discovery/setup and teardown
+ *	procedures should be performed by sending TDLS packets via
+ *	%NL80211_CMD_TDLS_MGMT. Otherwise %NL80211_CMD_TDLS_OPER should be
+ *	used for asking the driver to perform a TDLS operation.
+ *
+ * @NL80211_ATTR_DFS_REGION: region for regulatory rules which this country
+ *    abides to when initiating radiation on DFS channels. A country maps
+ *    to one DFS region.
  *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -1256,6 +1324,24 @@ enum nl80211_attrs {
 	NL80211_ATTR_IE_ASSOC_RESP,
 
 	NL80211_ATTR_STA_WME,
+	NL80211_ATTR_SUPPORT_AP_UAPSD,
+
+	NL80211_ATTR_ROAM_SUPPORT,
+
+	NL80211_ATTR_SCHED_SCAN_MATCH,
+	NL80211_ATTR_MAX_MATCH_SETS,
+
+	NL80211_ATTR_PMKSA_CANDIDATE,
+
+	NL80211_ATTR_TX_NO_CCK_RATE,
+
+	NL80211_ATTR_TDLS_ACTION,
+	NL80211_ATTR_TDLS_DIALOG_TOKEN,
+	NL80211_ATTR_TDLS_OPERATION,
+	NL80211_ATTR_TDLS_SUPPORT,
+	NL80211_ATTR_TDLS_EXTERNAL_SETUP,
+
+	NL80211_ATTR_DFS_REGION,
 
 	/* add attributes here, update the policy in nl80211.c */
 
@@ -1354,6 +1440,7 @@ enum nl80211_iftype {
  * @NL80211_STA_FLAG_WME: station is WME/QoS capable
  * @NL80211_STA_FLAG_MFP: station uses management frame protection
  * @NL80211_STA_FLAG_AUTHENTICATED: station is authenticated
+ * @NL80211_STA_FLAG_TDLS_PEER: station is a TDLS peer
  * @NL80211_STA_FLAG_MAX: highest station flag number currently defined
  * @__NL80211_STA_FLAG_AFTER_LAST: internal use
  */
@@ -1364,6 +1451,7 @@ enum nl80211_sta_flags {
 	NL80211_STA_FLAG_WME,
 	NL80211_STA_FLAG_MFP,
 	NL80211_STA_FLAG_AUTHENTICATED,
+	NL80211_STA_FLAG_TDLS_PEER,
 
 	/* keep last */
 	__NL80211_STA_FLAG_AFTER_LAST,
@@ -1716,6 +1804,26 @@ enum nl80211_reg_rule_attr {
 };
 
 /**
+ * enum nl80211_sched_scan_match_attr - scheduled scan match attributes
+ * @__NL80211_SCHED_SCAN_MATCH_ATTR_INVALID: attribute number 0 is reserved
+ * @NL80211_SCHED_SCAN_MATCH_ATTR_SSID: SSID to be used for matching,
+ * only report BSS with matching SSID.
+ * @NL80211_SCHED_SCAN_MATCH_ATTR_MAX: highest scheduled scan filter
+ *	attribute number currently defined
+ * @__NL80211_SCHED_SCAN_MATCH_ATTR_AFTER_LAST: internal use
+ */
+enum nl80211_sched_scan_match_attr {
+	__NL80211_SCHED_SCAN_MATCH_ATTR_INVALID,
+
+	NL80211_ATTR_SCHED_SCAN_MATCH_SSID,
+
+	/* keep last */
+	__NL80211_SCHED_SCAN_MATCH_ATTR_AFTER_LAST,
+	NL80211_SCHED_SCAN_MATCH_ATTR_MAX =
+		__NL80211_SCHED_SCAN_MATCH_ATTR_AFTER_LAST - 1
+};
+
+/**
  * enum nl80211_reg_rule_flags - regulatory rule flags
  *
  * @NL80211_RRF_NO_OFDM: OFDM modulation not allowed
@@ -1741,6 +1849,21 @@ enum nl80211_reg_rule_flags {
 };
 
 /**
+ * enum nl80211_dfs_regions - regulatory DFS regions
+ *
+ * @NL80211_DFS_UNSET: Country has no DFS master region specified
+ * @NL80211_DFS_FCC_: Country follows DFS master rules from FCC
+ * @NL80211_DFS_FCC_: Country follows DFS master rules from ETSI
+ * @NL80211_DFS_JP_: Country follows DFS master rules from JP/MKK/Telec
+ */
+enum nl80211_cflags {
+	NL80211_DFS_UNSET	= 0,
+	NL80211_DFS_FCC		= 1,
+	NL80211_DFS_ETSI	= 2,
+	NL80211_DFS_JP		= 3,
+};
+
+/**
  * enum nl80211_survey_info - survey information
  *
  * These attribute types are used with %NL80211_ATTR_SURVEY_INFO
@@ -2490,8 +2613,10 @@ enum nl80211_hidden_ssid {
 /**
  * enum nl80211_sta_wme_attr - station WME attributes
  * @__NL80211_STA_WME_INVALID: invalid number for nested attribute
- * @NL80211_STA_WME_QUEUES: bitmap of uapsd queues.
- * @NL80211_STA_WME_MAX_SP: max service period.
+ * @NL80211_STA_WME_UAPSD_QUEUES: bitmap of uapsd queues. the format
+ *	is the same as the AC bitmap in the QoS info field.
+ * @NL80211_STA_WME_MAX_SP: max service period. the format is the same
+ *	as the MAX_SP field in the QoS info field (but already shifted down).
  * @__NL80211_STA_WME_AFTER_LAST: internal
  * @NL80211_STA_WME_MAX: highest station WME attribute
  */
@@ -2505,4 +2630,43 @@ enum nl80211_sta_wme_attr {
 	NL80211_STA_WME_MAX = __NL80211_STA_WME_AFTER_LAST - 1
 };
 
+/**
+ * enum nl80211_pmksa_candidate_attr - attributes for PMKSA caching candidates
+ * @__NL80211_PMKSA_CANDIDATE_INVALID: invalid number for nested attributes
+ * @NL80211_PMKSA_CANDIDATE_INDEX: candidate index (u32; the smaller, the higher
+ *	priority)
+ * @NL80211_PMKSA_CANDIDATE_BSSID: candidate BSSID (6 octets)
+ * @NL80211_PMKSA_CANDIDATE_PREAUTH: RSN pre-authentication supported (flag)
+ * @NUM_NL80211_PMKSA_CANDIDATE: number of PMKSA caching candidate attributes
+ *	(internal)
+ * @MAX_NL80211_PMKSA_CANDIDATE: highest PMKSA caching candidate attribute
+ *	(internal)
+ */
+enum nl80211_pmksa_candidate_attr {
+	__NL80211_PMKSA_CANDIDATE_INVALID,
+	NL80211_PMKSA_CANDIDATE_INDEX,
+	NL80211_PMKSA_CANDIDATE_BSSID,
+	NL80211_PMKSA_CANDIDATE_PREAUTH,
+
+	/* keep last */
+	NUM_NL80211_PMKSA_CANDIDATE,
+	MAX_NL80211_PMKSA_CANDIDATE = NUM_NL80211_PMKSA_CANDIDATE - 1
+};
+
+/**
+ * enum nl80211_tdls_operation - values for %NL80211_ATTR_TDLS_OPERATION
+ * @NL80211_TDLS_DISCOVERY_REQ: Send a TDLS discovery request
+ * @NL80211_TDLS_SETUP: Setup TDLS link
+ * @NL80211_TDLS_TEARDOWN: Teardown a TDLS link which is already established
+ * @NL80211_TDLS_ENABLE_LINK: Enable TDLS link
+ * @NL80211_TDLS_DISABLE_LINK: Disable TDLS link
+ */
+enum nl80211_tdls_operation {
+	NL80211_TDLS_DISCOVERY_REQ,
+	NL80211_TDLS_SETUP,
+	NL80211_TDLS_TEARDOWN,
+	NL80211_TDLS_ENABLE_LINK,
+	NL80211_TDLS_DISABLE_LINK,
+};
+
 #endif /* __LINUX_NL80211_H */
-- 
1.7.4.15.g7811d

[PATCH 8/8] iw: add DFS region parsing support

[Luis R. Rodriguez]

This lets iw parse the DFS region passed on by the kernel
when one is found for the currently used regulatory domain.

Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
---
 reg.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/reg.c b/reg.c
index c4ee1c4..4fa5bec 100644
--- a/reg.c
+++ b/reg.c
@@ -96,6 +96,31 @@ COMMAND(reg, set, "<ISO/IEC 3166-1 alpha2>",
 	NL80211_CMD_REQ_SET_REG, 0, CIB_NONE, handle_reg_set,
 	"Notify the kernel about the current regulatory domain.");
 
+static void print_dfs_region(__u8 dfs_region)
+{
+	if (!dfs_region)
+		return;
+
+	printf("DFS Master region: ");
+
+	switch (dfs_region) {
+	case NL80211_DFS_FCC:
+		printf("FCC");
+		break;
+	case NL80211_DFS_ETSI:
+		printf("ETSI");
+		break;
+	case NL80211_DFS_JP:
+		printf("JP");
+		break;
+	default:
+		printf("Uknown");
+		break;
+	}
+
+	printf("\n");
+}
+
 static int print_reg_handler(struct nl_msg *msg, void *arg)
 
 {
@@ -107,6 +132,7 @@ static int print_reg_handler(struct nl_msg *msg, void *arg)
 	struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
 	struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
 	char *alpha2;
+	__u8 dfs_region = 0;
 	struct nlattr *nl_rule;
 	int rem_rule;
 	static struct nla_policy reg_rule_policy[NL80211_FREQUENCY_ATTR_MAX + 1] = {
@@ -132,7 +158,12 @@ static int print_reg_handler(struct nl_msg *msg, void *arg)
 	}
 
 	alpha2 = nla_data(tb_msg[NL80211_ATTR_REG_ALPHA2]);
+
+	if (tb_msg[NL80211_ATTR_DFS_REGION])
+		dfs_region = nla_get_u8(tb_msg[NL80211_ATTR_DFS_REGION]);
+
 	printf("country %c%c:\n", alpha2[0], alpha2[1]);
+	print_dfs_region(dfs_region);
 
 	nla_for_each_nested(nl_rule, tb_msg[NL80211_ATTR_REG_RULES], rem_rule) {
 		struct nlattr *tb_rule[NL80211_FREQUENCY_ATTR_MAX + 1];
-- 
1.7.4.15.g7811d

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
<mcgrof@qca.qualcomm.com> wrote:
> This set of 8 patches adds DFS master support to the Linux wireless subsystem.
> I've reviewed future possible changes to DFS master regions and it seems that
> we are not going to be having multiple DFS regions for one country, instead
> we'll always have one DFS region for one country.
>
> The changes here are spread out throughout wireless-regdb, crda the kernel and
> lastly iw. The changes made allow for older verions of CRDA to work with new
> wireless-regdb files with DFS region support. If you want DFS master region
> support you'll need to upgrade your CRDA, your kernel and then hope someone
> implements DFS master support for your respective driver.
>
> This patch series does not have specific driver changes, although some seem to
> be backing in the oven right now.

Here's a puzzle though... If we change this series to use the other
pad byte that was available, the first pad byte, instead of the last
one, we loose backward compatibility support and I cannot figure out
why. What I ended up seeing was that crda sends the message, and for
some reason (return code is 222 from nl_wait_for_ack(), whatever that
is) the kernel rejects it. I suspect it may have to do with some sort
of offset to the *other* data that makes some of the rules output
invalid data for the attribute policy, but at least when I hexdump the
wireless-regdb the only changes I see are in the signature and the pad
shift.

I got tired of trying though and after seeing flipping the pad bytes
things worked decided to stay with it. In my original RFC in December
I had used u16 instead, but since the data was in the last pad byte
things still worked. So something is fishy about only using the first
pad byte. The change below, as far as I can tell, should not have any
issues but it does with the older version of CRDA and even a new one.

diff --git a/db2bin.py b/db2bin.py
index 41d3741..ab335c2 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -116,7 +116,7 @@ countrynames.sort()
 for alpha2 in countrynames:
     coll = countries[alpha2]
     # struct regdb_file_reg_country
-    output.write(struct.pack('>ccxBI', str(alpha2[0]),
str(alpha2[1]), coll.dfs_region,
reg_rules_collections[coll.permissions]))
+    output.write(struct.pack('>ccBxI', str(alpha2[0]),
str(alpha2[1]), coll.dfs_region,
reg_rules_collections[coll.permissions]))


 if len(sys.argv) > 3:
diff --git a/regdb.h b/regdb.h
index b59115f..e7978dc 100644
--- a/regdb.h
+++ b/regdb.h
@@ -96,8 +96,8 @@ struct regdb_file_reg_rules_collection {

 struct regdb_file_reg_country {
 	__u8	alpha2[2];
-	__u8	PAD;
 	__u8	dfs_region;
+	__u8	PAD;
 	/* pointer (offset) into the file to a struct
 	 * regdb_file_reg_rules_collection */
 	__be32	reg_collection_ptr;

  Luis

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
<mcgrof@qca.qualcomm.com> wrote:
> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
> <mcgrof@qca.qualcomm.com> wrote:
>> This set of 8 patches adds DFS master support to the Linux wireless subsystem.
>> I've reviewed future possible changes to DFS master regions and it seems that
>> we are not going to be having multiple DFS regions for one country, instead
>> we'll always have one DFS region for one country.
>>
>> The changes here are spread out throughout wireless-regdb, crda the kernel and
>> lastly iw. The changes made allow for older verions of CRDA to work with new
>> wireless-regdb files with DFS region support. If you want DFS master region
>> support you'll need to upgrade your CRDA, your kernel and then hope someone
>> implements DFS master support for your respective driver.
>>
>> This patch series does not have specific driver changes, although some seem to
>> be backing in the oven right now.
>
> Here's a puzzle though... If we change this series to use the other
> pad byte that was available, the first pad byte, instead of the last
> one, we loose backward compatibility support and I cannot figure out
> why. What I ended up seeing was that crda sends the message, and for
> some reason (return code is 222 from nl_wait_for_ack(), whatever that
> is) the kernel rejects it. I suspect it may have to do with some sort
> of offset to the *other* data that makes some of the rules output
> invalid data for the attribute policy, but at least when I hexdump the
> wireless-regdb the only changes I see are in the signature and the pad
> shift.
>
> I got tired of trying though and after seeing flipping the pad bytes
> things worked decided to stay with it. In my original RFC in December
> I had used u16 instead, but since the data was in the last pad byte
> things still worked. So something is fishy about only using the first
> pad byte. The change below, as far as I can tell, should not have any
> issues but it does with the older version of CRDA and even a new one.

Johannes spotted the issue, I'll send the fix, thanks to Johannes.
John, Johannes the patches still apply my fix goes on top of these
changes, the fix is not addressing a regression introduced by this
patchset, instead it fixes a long standing issue which would prevent
us from using the next available pad byte.

  Luis

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
<mcgrof@qca.qualcomm.com> wrote:
> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
> <mcgrof@qca.qualcomm.com> wrote:
>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>> <mcgrof@qca.qualcomm.com> wrote:
>>> This set of 8 patches adds DFS master support to the Linux wireless subsystem.
>>> I've reviewed future possible changes to DFS master regions and it seems that
>>> we are not going to be having multiple DFS regions for one country, instead
>>> we'll always have one DFS region for one country.
>>>
>>> The changes here are spread out throughout wireless-regdb, crda the kernel and
>>> lastly iw. The changes made allow for older verions of CRDA to work with new
>>> wireless-regdb files with DFS region support. If you want DFS master region
>>> support you'll need to upgrade your CRDA, your kernel and then hope someone
>>> implements DFS master support for your respective driver.
>>>
>>> This patch series does not have specific driver changes, although some seem to
>>> be backing in the oven right now.
>>
>> Here's a puzzle though... If we change this series to use the other
>> pad byte that was available, the first pad byte, instead of the last
>> one, we loose backward compatibility support and I cannot figure out
>> why. What I ended up seeing was that crda sends the message, and for
>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>> is) the kernel rejects it. I suspect it may have to do with some sort
>> of offset to the *other* data that makes some of the rules output
>> invalid data for the attribute policy, but at least when I hexdump the
>> wireless-regdb the only changes I see are in the signature and the pad
>> shift.
>>
>> I got tired of trying though and after seeing flipping the pad bytes
>> things worked decided to stay with it. In my original RFC in December
>> I had used u16 instead, but since the data was in the last pad byte
>> things still worked. So something is fishy about only using the first
>> pad byte. The change below, as far as I can tell, should not have any
>> issues but it does with the older version of CRDA and even a new one.
>
> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
> John, Johannes the patches still apply my fix goes on top of these
> changes, the fix is not addressing a regression introduced by this
> patchset, instead it fixes a long standing issue which would prevent
> us from using the next available pad byte.

I'm going to respin this to make use of 2 bits:

00 unset
01 FCC
10 ETSI
11 JP

We may need some more DFS values later but

  Luis

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Fri, Oct 7, 2011 at 3:29 PM, Luis R. Rodriguez
<mcgrof@qca.qualcomm.com> wrote:
> On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
> <mcgrof@qca.qualcomm.com> wrote:
>> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
>> <mcgrof@qca.qualcomm.com> wrote:
>>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>>> <mcgrof@qca.qualcomm.com> wrote:
>>>> This set of 8 patches adds DFS master support to the Linux wireless subsystem.
>>>> I've reviewed future possible changes to DFS master regions and it seems that
>>>> we are not going to be having multiple DFS regions for one country, instead
>>>> we'll always have one DFS region for one country.
>>>>
>>>> The changes here are spread out throughout wireless-regdb, crda the kernel and
>>>> lastly iw. The changes made allow for older verions of CRDA to work with new
>>>> wireless-regdb files with DFS region support. If you want DFS master region
>>>> support you'll need to upgrade your CRDA, your kernel and then hope someone
>>>> implements DFS master support for your respective driver.
>>>>
>>>> This patch series does not have specific driver changes, although some seem to
>>>> be backing in the oven right now.
>>>
>>> Here's a puzzle though... If we change this series to use the other
>>> pad byte that was available, the first pad byte, instead of the last
>>> one, we loose backward compatibility support and I cannot figure out
>>> why. What I ended up seeing was that crda sends the message, and for
>>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>>> is) the kernel rejects it. I suspect it may have to do with some sort
>>> of offset to the *other* data that makes some of the rules output
>>> invalid data for the attribute policy, but at least when I hexdump the
>>> wireless-regdb the only changes I see are in the signature and the pad
>>> shift.
>>>
>>> I got tired of trying though and after seeing flipping the pad bytes
>>> things worked decided to stay with it. In my original RFC in December
>>> I had used u16 instead, but since the data was in the last pad byte
>>> things still worked. So something is fishy about only using the first
>>> pad byte. The change below, as far as I can tell, should not have any
>>> issues but it does with the older version of CRDA and even a new one.
>>
>> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
>> John, Johannes the patches still apply my fix goes on top of these
>> changes, the fix is not addressing a regression introduced by this
>> patchset, instead it fixes a long standing issue which would prevent
>> us from using the next available pad byte.
>
> I'm going to respin this to make use of 2 bits:
>
> 00 unset
> 01 FCC
> 10 ETSI
> 11 JP
>
> We may need some more DFS values later but

Sorry I did not finish this e-mail I meant that we may later have a
requirement for more DFS values but at this time we don't, we should
consider whether or not we will want to leave more bits for usage of
more DFS values and if so how many? Using two bits will give us
support for what we know today but nothing for the future.

If I use two bits I just don't want complains later if we have DFS
regions split in the db spec for future changes.

  Luis

Re: [PATCH 0/8] wireless: add DFS master support

[Zefir Kurtisi]

On 08.10.2011 00:32, Luis R. Rodriguez wrote:
> On Fri, Oct 7, 2011 at 3:29 PM, Luis R. Rodriguez
> <mcgrof@qca.qualcomm.com>  wrote:
>> On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
>> <mcgrof@qca.qualcomm.com>  wrote:
>>> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>> This set of 8 patches adds DFS master support to the Linux wireless subsystem.
>>>>> I've reviewed future possible changes to DFS master regions and it seems that
>>>>> we are not going to be having multiple DFS regions for one country, instead
>>>>> we'll always have one DFS region for one country.
>>>>>
>>>>> The changes here are spread out throughout wireless-regdb, crda the kernel and
>>>>> lastly iw. The changes made allow for older verions of CRDA to work with new
>>>>> wireless-regdb files with DFS region support. If you want DFS master region
>>>>> support you'll need to upgrade your CRDA, your kernel and then hope someone
>>>>> implements DFS master support for your respective driver.
>>>>>
>>>>> This patch series does not have specific driver changes, although some seem to
>>>>> be backing in the oven right now.
>>>>
>>>> Here's a puzzle though... If we change this series to use the other
>>>> pad byte that was available, the first pad byte, instead of the last
>>>> one, we loose backward compatibility support and I cannot figure out
>>>> why. What I ended up seeing was that crda sends the message, and for
>>>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>>>> is) the kernel rejects it. I suspect it may have to do with some sort
>>>> of offset to the *other* data that makes some of the rules output
>>>> invalid data for the attribute policy, but at least when I hexdump the
>>>> wireless-regdb the only changes I see are in the signature and the pad
>>>> shift.
>>>>
>>>> I got tired of trying though and after seeing flipping the pad bytes
>>>> things worked decided to stay with it. In my original RFC in December
>>>> I had used u16 instead, but since the data was in the last pad byte
>>>> things still worked. So something is fishy about only using the first
>>>> pad byte. The change below, as far as I can tell, should not have any
>>>> issues but it does with the older version of CRDA and even a new one.
>>>
>>> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
>>> John, Johannes the patches still apply my fix goes on top of these
>>> changes, the fix is not addressing a regression introduced by this
>>> patchset, instead it fixes a long standing issue which would prevent
>>> us from using the next available pad byte.
>>
>> I'm going to respin this to make use of 2 bits:
>>
>> 00 unset
>> 01 FCC
>> 10 ETSI
>> 11 JP
>>
>> We may need some more DFS values later but
>
> Sorry I did not finish this e-mail I meant that we may later have a
> requirement for more DFS values but at this time we don't, we should
> consider whether or not we will want to leave more bits for usage of
> more DFS values and if so how many? Using two bits will give us
> support for what we know today but nothing for the future.
>
For the future things we do not know of today we should add another bit 
and define

111 unknown / other

to be able to mark special countrycodes that do not fully belong to the 
three known domains. We could use some invalid coding for those CCs 
(like no DFS domain set in CC but flag set for frequency band) to 
identify those special domains, but using an additional bit would make 
things easier to handle.

> If I use two bits I just don't want complains later if we have DFS
> regions split in the db spec for future changes.
>
>    Luis

Zefir

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Sat, Oct 8, 2011 at 10:46 AM, Zefir Kurtisi
<zefir.kurtisi@neratec.com> wrote:
> On 08.10.2011 00:32, Luis R. Rodriguez wrote:
>>
>> On Fri, Oct 7, 2011 at 3:29 PM, Luis R. Rodriguez
>> <mcgrof@qca.qualcomm.com>  wrote:
>>>
>>> On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>
>>>> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>
>>>>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>>
>>>>>> This set of 8 patches adds DFS master support to the Linux wireless
>>>>>> subsystem.
>>>>>> I've reviewed future possible changes to DFS master regions and it
>>>>>> seems that
>>>>>> we are not going to be having multiple DFS regions for one country,
>>>>>> instead
>>>>>> we'll always have one DFS region for one country.
>>>>>>
>>>>>> The changes here are spread out throughout wireless-regdb, crda the
>>>>>> kernel and
>>>>>> lastly iw. The changes made allow for older verions of CRDA to work
>>>>>> with new
>>>>>> wireless-regdb files with DFS region support. If you want DFS master
>>>>>> region
>>>>>> support you'll need to upgrade your CRDA, your kernel and then hope
>>>>>> someone
>>>>>> implements DFS master support for your respective driver.
>>>>>>
>>>>>> This patch series does not have specific driver changes, although some
>>>>>> seem to
>>>>>> be backing in the oven right now.
>>>>>
>>>>> Here's a puzzle though... If we change this series to use the other
>>>>> pad byte that was available, the first pad byte, instead of the last
>>>>> one, we loose backward compatibility support and I cannot figure out
>>>>> why. What I ended up seeing was that crda sends the message, and for
>>>>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>>>>> is) the kernel rejects it. I suspect it may have to do with some sort
>>>>> of offset to the *other* data that makes some of the rules output
>>>>> invalid data for the attribute policy, but at least when I hexdump the
>>>>> wireless-regdb the only changes I see are in the signature and the pad
>>>>> shift.
>>>>>
>>>>> I got tired of trying though and after seeing flipping the pad bytes
>>>>> things worked decided to stay with it. In my original RFC in December
>>>>> I had used u16 instead, but since the data was in the last pad byte
>>>>> things still worked. So something is fishy about only using the first
>>>>> pad byte. The change below, as far as I can tell, should not have any
>>>>> issues but it does with the older version of CRDA and even a new one.
>>>>
>>>> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
>>>> John, Johannes the patches still apply my fix goes on top of these
>>>> changes, the fix is not addressing a regression introduced by this
>>>> patchset, instead it fixes a long standing issue which would prevent
>>>> us from using the next available pad byte.
>>>
>>> I'm going to respin this to make use of 2 bits:
>>>
>>> 00 unset
>>> 01 FCC
>>> 10 ETSI
>>> 11 JP
>>>
>>> We may need some more DFS values later but
>>
>> Sorry I did not finish this e-mail I meant that we may later have a
>> requirement for more DFS values but at this time we don't, we should
>> consider whether or not we will want to leave more bits for usage of
>> more DFS values and if so how many? Using two bits will give us
>> support for what we know today but nothing for the future.
>>
> For the future things we do not know of today we should add another bit and
> define
>
> 111 unknown / other
>
> to be able to mark special countrycodes that do not fully belong to the
> three known domains.

I thought about this a bit more, so we'd have to define this as a U8
attribute either way, so I would instead of calling NL80211_DFS_REGION
call it something like NL80211_CTRY_REQS and for now only use 2 bits
for the known DFS regions. We'd mask out the rest of the values. If we
ever decide we need a new DFS region we could just extend the values
on NL80211_CTRY_REQS after the last region. If we want to add a new
requirement that is country specific other than DFS we could start at
the end of the u8 instead of after the last DFS region. We could do
this without making any explicit reservations.

> We could use some invalid coding for those CCs (like no
> DFS domain set in CC

Sure, I should point out today every single regulatory domain will
have this set except US, only because I added a patch to match US to
DFS-FCC DFS region.

> but flag set for frequency band) to identify those
> special domains,

So you're saying in case later we find out we need band specific DFS data later?

> but using an additional bit would make things easier to
> handle.

We can extend this as we go, and just ensure upon review of new code
that we accommodate non -DFS crap at the end of the u8. Whatdya think?

  Luis

Re: [PATCH 0/8] wireless: add DFS master support

[Johannes Berg]

On Sat, 2011-10-08 at 11:26 -0700, Luis R. Rodriguez wrote:

> > 111 unknown / other
> >
> > to be able to mark special countrycodes that do not fully belong to the
> > three known domains.
> 
> I thought about this a bit more, so we'd have to define this as a U8
> attribute either way, so I would instead of calling NL80211_DFS_REGION
> call it something like NL80211_CTRY_REQS and for now only use 2 bits
> for the known DFS regions. We'd mask out the rest of the values. If we
> ever decide we need a new DFS region we could just extend the values
> on NL80211_CTRY_REQS after the last region. If we want to add a new
> requirement that is country specific other than DFS we could start at
> the end of the u8 instead of after the last DFS region. We could do
> this without making any explicit reservations.

I'm not sure I understand this fully, but the bitfield usage should
really be restricted to the database on-disk format; the nl80211 API
isn't restricted by byte shortages to start with :)

johannes

Re: [PATCH 0/8] wireless: add DFS master support

[Zefir Kurtisi]

On 10/08/2011 08:26 PM, Luis R. Rodriguez wrote:
> On Sat, Oct 8, 2011 at 10:46 AM, Zefir Kurtisi
> <zefir.kurtisi@neratec.com> wrote:
>> On 08.10.2011 00:32, Luis R. Rodriguez wrote:
>>>
>>> On Fri, Oct 7, 2011 at 3:29 PM, Luis R. Rodriguez
>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>
>>>> On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>
>>>>> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
>>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>>
>>>>>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>>>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>>>
>>>>>>> This set of 8 patches adds DFS master support to the Linux wireless
>>>>>>> subsystem.
>>>>>>> I've reviewed future possible changes to DFS master regions and it
>>>>>>> seems that
>>>>>>> we are not going to be having multiple DFS regions for one country,
>>>>>>> instead
>>>>>>> we'll always have one DFS region for one country.
>>>>>>>
>>>>>>> The changes here are spread out throughout wireless-regdb, crda the
>>>>>>> kernel and
>>>>>>> lastly iw. The changes made allow for older verions of CRDA to work
>>>>>>> with new
>>>>>>> wireless-regdb files with DFS region support. If you want DFS master
>>>>>>> region
>>>>>>> support you'll need to upgrade your CRDA, your kernel and then hope
>>>>>>> someone
>>>>>>> implements DFS master support for your respective driver.
>>>>>>>
>>>>>>> This patch series does not have specific driver changes, although some
>>>>>>> seem to
>>>>>>> be backing in the oven right now.
>>>>>>
>>>>>> Here's a puzzle though... If we change this series to use the other
>>>>>> pad byte that was available, the first pad byte, instead of the last
>>>>>> one, we loose backward compatibility support and I cannot figure out
>>>>>> why. What I ended up seeing was that crda sends the message, and for
>>>>>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>>>>>> is) the kernel rejects it. I suspect it may have to do with some sort
>>>>>> of offset to the *other* data that makes some of the rules output
>>>>>> invalid data for the attribute policy, but at least when I hexdump the
>>>>>> wireless-regdb the only changes I see are in the signature and the pad
>>>>>> shift.
>>>>>>
>>>>>> I got tired of trying though and after seeing flipping the pad bytes
>>>>>> things worked decided to stay with it. In my original RFC in December
>>>>>> I had used u16 instead, but since the data was in the last pad byte
>>>>>> things still worked. So something is fishy about only using the first
>>>>>> pad byte. The change below, as far as I can tell, should not have any
>>>>>> issues but it does with the older version of CRDA and even a new one.
>>>>>
>>>>> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
>>>>> John, Johannes the patches still apply my fix goes on top of these
>>>>> changes, the fix is not addressing a regression introduced by this
>>>>> patchset, instead it fixes a long standing issue which would prevent
>>>>> us from using the next available pad byte.
>>>>
>>>> I'm going to respin this to make use of 2 bits:
>>>>
>>>> 00 unset
>>>> 01 FCC
>>>> 10 ETSI
>>>> 11 JP
>>>>
>>>> We may need some more DFS values later but
>>>
>>> Sorry I did not finish this e-mail I meant that we may later have a
>>> requirement for more DFS values but at this time we don't, we should
>>> consider whether or not we will want to leave more bits for usage of
>>> more DFS values and if so how many? Using two bits will give us
>>> support for what we know today but nothing for the future.
>>>
>> For the future things we do not know of today we should add another bit and
>> define
>>
>> 111 unknown / other
>>
>> to be able to mark special countrycodes that do not fully belong to the
>> three known domains.
> 
> I thought about this a bit more, so we'd have to define this as a U8
> attribute either way, so I would instead of calling NL80211_DFS_REGION
> call it something like NL80211_CTRY_REQS and for now only use 2 bits
> for the known DFS regions. We'd mask out the rest of the values. If we
> ever decide we need a new DFS region we could just extend the values
> on NL80211_CTRY_REQS after the last region. If we want to add a new
> requirement that is country specific other than DFS we could start at
> the end of the u8 instead of after the last DFS region. We could do
> this without making any explicit reservations.
> 
>> We could use some invalid coding for those CCs (like no
>> DFS domain set in CC
> 
> Sure, I should point out today every single regulatory domain will
> have this set except US, only because I added a patch to match US to
> DFS-FCC DFS region.
> 
>> but flag set for frequency band) to identify those
>> special domains,
> 
> So you're saying in case later we find out we need band specific DFS data later?
> 
No, I guess I initially misinterpreted the meaning of '00 unset' as a flag for countrycodes not restricted by DFS at all, but in fact this is done by not setting the per-band DFS flags.

So, if we consider the per-country DFS domain as an enabler for DFS support on top of per-band DFS restrictions (that otherwise remain disabled), we can support 'fancy' CCs by not setting the domain. The concern I brought up is therefore void.

WRT band specific DFS data, we agreed that this will break backwards compatibility and therefore needs some detailed planning. Adrian already brought up some issues we will face and why he is using per-band (or even per-channel) DFS properties.

I opt for keeping this proposed per-country DFS domain scheme until we get DFS fully working and find its limitations significant enough to start a major revision.

>> but using an additional bit would make things easier to
>> handle.
> 
> We can extend this as we go, and just ensure upon review of new code
> that we accommodate non -DFS crap at the end of the u8. Whatdya think?
> 
>   Luis

Zefir

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Mon, Oct 10, 2011 at 2:13 AM, Zefir Kurtisi
<zefir.kurtisi@neratec.com> wrote:
> On 10/08/2011 08:26 PM, Luis R. Rodriguez wrote:
>> On Sat, Oct 8, 2011 at 10:46 AM, Zefir Kurtisi
>> <zefir.kurtisi@neratec.com> wrote:
>>> On 08.10.2011 00:32, Luis R. Rodriguez wrote:
>>>>
>>>> On Fri, Oct 7, 2011 at 3:29 PM, Luis R. Rodriguez
>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>
>>>>> On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
>>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>>
>>>>>> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
>>>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>>>
>>>>>>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>>>>>>> <mcgrof@qca.qualcomm.com>  wrote:
>>>>>>>>
>>>>>>>> This set of 8 patches adds DFS master support to the Linux wireless
>>>>>>>> subsystem.
>>>>>>>> I've reviewed future possible changes to DFS master regions and it
>>>>>>>> seems that
>>>>>>>> we are not going to be having multiple DFS regions for one country,
>>>>>>>> instead
>>>>>>>> we'll always have one DFS region for one country.
>>>>>>>>
>>>>>>>> The changes here are spread out throughout wireless-regdb, crda the
>>>>>>>> kernel and
>>>>>>>> lastly iw. The changes made allow for older verions of CRDA to work
>>>>>>>> with new
>>>>>>>> wireless-regdb files with DFS region support. If you want DFS master
>>>>>>>> region
>>>>>>>> support you'll need to upgrade your CRDA, your kernel and then hope
>>>>>>>> someone
>>>>>>>> implements DFS master support for your respective driver.
>>>>>>>>
>>>>>>>> This patch series does not have specific driver changes, although some
>>>>>>>> seem to
>>>>>>>> be backing in the oven right now.
>>>>>>>
>>>>>>> Here's a puzzle though... If we change this series to use the other
>>>>>>> pad byte that was available, the first pad byte, instead of the last
>>>>>>> one, we loose backward compatibility support and I cannot figure out
>>>>>>> why. What I ended up seeing was that crda sends the message, and for
>>>>>>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>>>>>>> is) the kernel rejects it. I suspect it may have to do with some sort
>>>>>>> of offset to the *other* data that makes some of the rules output
>>>>>>> invalid data for the attribute policy, but at least when I hexdump the
>>>>>>> wireless-regdb the only changes I see are in the signature and the pad
>>>>>>> shift.
>>>>>>>
>>>>>>> I got tired of trying though and after seeing flipping the pad bytes
>>>>>>> things worked decided to stay with it. In my original RFC in December
>>>>>>> I had used u16 instead, but since the data was in the last pad byte
>>>>>>> things still worked. So something is fishy about only using the first
>>>>>>> pad byte. The change below, as far as I can tell, should not have any
>>>>>>> issues but it does with the older version of CRDA and even a new one.
>>>>>>
>>>>>> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
>>>>>> John, Johannes the patches still apply my fix goes on top of these
>>>>>> changes, the fix is not addressing a regression introduced by this
>>>>>> patchset, instead it fixes a long standing issue which would prevent
>>>>>> us from using the next available pad byte.
>>>>>
>>>>> I'm going to respin this to make use of 2 bits:
>>>>>
>>>>> 00 unset
>>>>> 01 FCC
>>>>> 10 ETSI
>>>>> 11 JP
>>>>>
>>>>> We may need some more DFS values later but
>>>>
>>>> Sorry I did not finish this e-mail I meant that we may later have a
>>>> requirement for more DFS values but at this time we don't, we should
>>>> consider whether or not we will want to leave more bits for usage of
>>>> more DFS values and if so how many? Using two bits will give us
>>>> support for what we know today but nothing for the future.
>>>>
>>> For the future things we do not know of today we should add another bit and
>>> define
>>>
>>> 111 unknown / other
>>>
>>> to be able to mark special countrycodes that do not fully belong to the
>>> three known domains.
>>
>> I thought about this a bit more, so we'd have to define this as a U8
>> attribute either way, so I would instead of calling NL80211_DFS_REGION
>> call it something like NL80211_CTRY_REQS and for now only use 2 bits
>> for the known DFS regions. We'd mask out the rest of the values. If we
>> ever decide we need a new DFS region we could just extend the values
>> on NL80211_CTRY_REQS after the last region. If we want to add a new
>> requirement that is country specific other than DFS we could start at
>> the end of the u8 instead of after the last DFS region. We could do
>> this without making any explicit reservations.
>>
>>> We could use some invalid coding for those CCs (like no
>>> DFS domain set in CC
>>
>> Sure, I should point out today every single regulatory domain will
>> have this set except US, only because I added a patch to match US to
>> DFS-FCC DFS region.
>>
>>> but flag set for frequency band) to identify those
>>> special domains,
>>
>> So you're saying in case later we find out we need band specific DFS data later?
>>
> No, I guess I initially misinterpreted the meaning of '00 unset' as a flag for countrycodes not restricted by DFS at all, but in fact this is done by not setting the per-band DFS flags.
>
> So, if we consider the per-country DFS domain as an enabler for DFS support on top of per-band DFS restrictions (that otherwise remain disabled), we can support 'fancy' CCs by not setting the domain. The concern I brought up is therefore void.
>
> WRT band specific DFS data, we agreed that this will break backwards compatibility and therefore needs some detailed planning. Adrian already brought up some issues we will face and why he is using per-band (or even per-channel) DFS properties.
>
> I opt for keeping this proposed per-country DFS domain scheme until we get DFS fully working and find its limitations significant enough to start a major revision.

Sure, I'll respin my patches to use only 2 bits for now on the
wireless-regdb. As far as nl80211 is concerned though since we can
only send U8 as a minimum I'll define this as a NL80211_CTRY_REQS and
we can stuff whatever we want into it later on CRDA.

  Luis

Re: [PATCH 0/8] wireless: add DFS master support

[Luis R. Rodriguez]

On Mon, Oct 10, 2011 at 12:05 PM, Luis R. Rodriguez
<mcgrof@qca.qualcomm.com> wrote:
> Sure, I'll respin my patches to use only 2 bits for now on the
> wireless-regdb. As far as nl80211 is concerned though since we can
> only send U8 as a minimum I'll define this as a NL80211_CTRY_REQS and
> we can stuff whatever we want into it later on CRDA.

And more to Johannes' point, my kernel patches can go as-is, the only
one that needs to deal with the nastiness is crda.c, not even the
wireless-regdb patches need to be respin'd. I did make a typo on
nl80211.h though so I will have to respin, also for the sake of
clarity.

  Luis