[PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()

[PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()

[Luis R. Rodriguez]

This series contains a few fixes for cfg80211 such as another
fix for parsing country IEs, but mostly contains work to help
drivers build a more useful reg_notifier(). While at it we remove
the CONFIG_WIRELESS_OLD_REGULATORY as we are now on road to 2.6.30.

Luis R. Rodriguez (12):
  cfg80211: print correct intersected regulatory domain
  cfg80211: add helper to indicate when to follow the driver regd
  cfg80211: add option for wiphys to disregard country IEs
  cfg80211: split wiphy_update_regulatory() in two
  cfg80211: add regulatory_set_custom_rd()
  cfg80211: add regdom_intersect_wiphy_regd()
  cfg80211: allow driver read access to cfg80211_regdomain
  cfg80211: export freq_reg_info()
  cfg80211: Fix sanity check on 5 GHz when processing country IE
  cfg80211: process user requests only after previous user/driver/core
    requests
  mac80211: allow mac80211 drivers to get to driver priv from wiphy
  cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

 Documentation/feature-removal-schedule.txt |   18 --
 include/net/mac80211.h                     |   11 +
 include/net/wireless.h                     |   63 ++++++
 net/mac80211/util.c                        |    9 +
 net/wireless/Kconfig                       |   46 ++---
 net/wireless/reg.c                         |  293 ++++++++++------------------
 6 files changed, 199 insertions(+), 241 deletions(-)

[PATCH 01/12] cfg80211: print correct intersected regulatory domain

[Luis R. Rodriguez]

When CONFIG_CFG80211_REG_DEBUG is enabled and an intersection
occurs we are printing the regulatory domain passed by CRDA
and indicating its the intersected regulatory domain. Lets fix
this and print the intersection as originally intended.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/wireless/reg.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index b34fd84..ec8b3d9 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1332,7 +1332,7 @@ static void reg_country_ie_process_debug(
 	if (intersected_rd) {
 		printk(KERN_DEBUG "cfg80211: We intersect both of these "
 			"and get:\n");
-		print_regdomain_info(rd);
+		print_regdomain_info(intersected_rd);
 		return;
 	}
 	printk(KERN_DEBUG "cfg80211: Intersection between both failed\n");
-- 
1.6.1.rc3.51.g5832d

[PATCH 02/12] cfg80211: add helper to indicate when to follow the driver regd

[Luis R. Rodriguez]

This adds a helper which which tells us when we need to follow
the driver's own regulatory domain. This will later be expanded.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/wireless/reg.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index ec8b3d9..1a5b37a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -782,6 +782,16 @@ static u32 map_regdom_flags(u32 rd_flags)
 	return channel_flags;
 }
 
+/* Follow the driver's regulatory domain, if present, unless a country
+ * IE has been processed */
+static int reg_follow_driver_regd(struct wiphy *wiphy)
+{
+	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE &&
+	    wiphy->regd)
+		return true;
+	return false;
+}
+
 /**
  * freq_reg_info - get regulatory information for the given frequency
  * @wiphy: the wiphy for which we want to process this rule for
@@ -813,10 +823,7 @@ static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
 
 	regd = cfg80211_regdomain;
 
-	/* Follow the driver's regulatory domain, if present, unless a country
-	 * IE has been processed */
-	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE &&
-	    wiphy->regd)
+	if (reg_follow_driver_regd(wiphy))
 		regd = wiphy->regd;
 
 	if (!regd)
-- 
1.6.1.rc3.51.g5832d

[PATCH 03/12] cfg80211: add option for wiphys to disregard country IEs

[Luis R. Rodriguez]

Country IEs can be disregarded based on regulatory policy by
a driver. This is only possible, of course, if the driver already
has its own regulatory domain.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/net/wireless.h |    4 ++++
 net/wireless/reg.c     |   17 +++++++++++------
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/include/net/wireless.h b/include/net/wireless.h
index 9e73aae..ea89958 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -181,6 +181,9 @@ struct ieee80211_supported_band {
  * struct wiphy - wireless hardware description
  * @idx: the wiphy index assigned to this item
  * @class_dev: the class device representing /sys/class/ieee80211/<wiphy-name>
+ * @ignore_country_ies: tells us the wireless core should ignore country IEs
+ *	received by itself or by other wireless drivers. This will only
+ *	apply if the driver has provided a regulatory_hint()
  * @fw_handles_regulatory: tells us the firmware for this device
  * 	has its own regulatory solution and cannot identify the
  * 	ISO / IEC 3166 alpha2 it belongs to. When this is enabled
@@ -202,6 +205,7 @@ struct wiphy {
 	u16 interface_modes;
 
 	bool fw_handles_regulatory;
+	bool ignore_country_ies;
 
 	/* If multiple wiphys are registered and you're handed e.g.
 	 * a regular netdev with assigned ieee80211_ptr, you won't
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 1a5b37a..49c9c25 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -782,12 +782,16 @@ static u32 map_regdom_flags(u32 rd_flags)
 	return channel_flags;
 }
 
-/* Follow the driver's regulatory domain, if present, unless a country
- * IE has been processed */
+/* Follow the driver's regulatory domain if a driver always prefers
+ * that. If no preference is specified we follow the driver's regulatory
+ * domain unless a country IE has been processed */
 static int reg_follow_driver_regd(struct wiphy *wiphy)
 {
-	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE &&
-	    wiphy->regd)
+	if (!wiphy->regd)
+		return false;
+	if (wiphy->ignore_country_ies)
+		return true;
+	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE)
 		return true;
 	return false;
 }
@@ -890,7 +894,7 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 		 *
 		 * http://tinyurl.com/11d-clarification
 		 */
-		if (r == -ERANGE &&
+		if (!reg_follow_driver_regd(wiphy) && r == -ERANGE &&
 		    last_request->initiator == REGDOM_SET_BY_COUNTRY_IE) {
 #ifdef CONFIG_CFG80211_REG_DEBUG
 			printk(KERN_DEBUG "cfg80211: Leaving channel %d MHz "
@@ -902,7 +906,8 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 		/* In this case we know the country IE has at least one reg rule
 		 * for the band so we respect its band definitions */
 #ifdef CONFIG_CFG80211_REG_DEBUG
-			if (last_request->initiator == REGDOM_SET_BY_COUNTRY_IE)
+			if (!reg_follow_driver_regd(wiphy) &&
+			    last_request->initiator == REGDOM_SET_BY_COUNTRY_IE)
 				printk(KERN_DEBUG "cfg80211: Disabling "
 					"channel %d MHz on %s due to "
 					"Country IE\n",
-- 
1.6.1.rc3.51.g5832d

[PATCH 04/12] cfg80211: split wiphy_update_regulatory() in two

[Luis R. Rodriguez]

This splits up wiphy_update_regulatory() in two parts, the
first can be used by other internal cfg80211 regulatory routines
to avoid calling the reg_notifier() if not needed.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/wireless/reg.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 49c9c25..127bec2 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -963,13 +963,18 @@ static void update_all_wiphy_regulatory(enum reg_set_by setby)
 			wiphy_update_regulatory(&drv->wiphy, setby);
 }
 
-void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
+static void regd_update_regulatory(struct wiphy *wiphy)
 {
 	enum ieee80211_band band;
 	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
 		if (wiphy->bands[band])
 			handle_band(wiphy, band);
 	}
+}
+
+void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
+{
+	regd_update_regulatory(wiphy);
 	if (wiphy->reg_notifier)
 		wiphy->reg_notifier(wiphy, setby);
 }
-- 
1.6.1.rc3.51.g5832d

[PATCH 05/12] cfg80211: add regulatory_set_custom_rd()

[Luis R. Rodriguez]

This adds regulatory_set_custom_rd() to allow drivers to apply custom
regulatory domains to their wireless device. This is required on drivers
that do not have a direct 1-1 mapping between a regugulatory domain and a
country. This applies to custom "world regulatory domains" which vendors
may use.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/net/wireless.h |   20 +++++++++++++++++++-
 net/wireless/reg.c     |   17 +++++++++++++++++
 2 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/include/net/wireless.h b/include/net/wireless.h
index ea89958..16f020a 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -183,7 +183,8 @@ struct ieee80211_supported_band {
  * @class_dev: the class device representing /sys/class/ieee80211/<wiphy-name>
  * @ignore_country_ies: tells us the wireless core should ignore country IEs
  *	received by itself or by other wireless drivers. This will only
- *	apply if the driver has provided a regulatory_hint()
+ *	apply if the driver has provided its own regulatory domain via
+ *	regulatory_hint() or regulatory_set_custom_rd()
  * @fw_handles_regulatory: tells us the firmware for this device
  * 	has its own regulatory solution and cannot identify the
  * 	ISO / IEC 3166 alpha2 it belongs to. When this is enabled
@@ -405,4 +406,21 @@ extern void regulatory_hint(struct wiphy *wiphy, const char *alpha2);
 extern void regulatory_hint_11d(struct wiphy *wiphy,
 				u8 *country_ie,
 				u8 country_ie_len);
+
+/**
+ * regulatory_set_custom_rd - apply a custom driver regulatory domain
+ * @wiphy: the wireless device we want to process the regulatory domain on
+ * @custom_regd: the custom regulatory domain to use for this wiphy
+ *
+ * Drivers can sometimes have custom regulatory domains which do not apply
+ * to a specific country. Drivers can use this to apply such custom regulatory
+ * domains. The custom regulatory domain will be copied into a new wiphy->regd
+ * for internal usage within cfg80211. The driver is in charge of freeing
+ * the passed regulatory domain if created using kmalloc(). This can be called
+ * after the wiphy has been registered with cfg80211.
+ */
+extern int regulatory_set_custom_rd(
+	struct wiphy *wiphy,
+	const struct ieee80211_regdomain *custom_regd);
+
 #endif /* __NET_WIRELESS_H */
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 127bec2..b05df36 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1003,6 +1003,23 @@ static int reg_copy_regd(const struct ieee80211_regdomain **dst_regd,
 	return 0;
 }
 
+int regulatory_set_custom_rd(struct wiphy *wiphy,
+			       const struct ieee80211_regdomain *custom_regd)
+{
+	int r = 0;
+	mutex_lock(&cfg80211_drv_mutex);
+	r = reg_copy_regd(&wiphy->regd, custom_regd);
+	if (r)
+		goto unlock;
+	regd_update_regulatory(wiphy);
+	if (wiphy->reg_notifier)
+		wiphy->reg_notifier(wiphy, REGDOM_SET_BY_DRIVER);
+unlock:
+	mutex_unlock(&cfg80211_drv_mutex);
+	return r;
+}
+EXPORT_SYMBOL(regulatory_set_custom_rd);
+
 /* Return value which can be used by ignore_request() to indicate
  * it has been determined we should intersect two regulatory domains */
 #define REG_INTERSECT	1
-- 
1.6.1.rc3.51.g5832d

[PATCH 06/12] cfg80211: add regdom_intersect_wiphy_regd()

[Luis R. Rodriguez]

This adds regdom_intersect_wiphy_regd() which can be used by drivers
on their reg_notifier() to further restrict the device's regulatory domain.
This is important for devices where calibration outside of the device's
supported regulatory domain is not supported or certified through proper
testing for operation.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/net/wireless.h |   14 ++++++++++++++
 net/wireless/reg.c     |   15 +++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/include/net/wireless.h b/include/net/wireless.h
index 16f020a..cb04e7b 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -423,4 +423,18 @@ extern int regulatory_set_custom_rd(
 	struct wiphy *wiphy,
 	const struct ieee80211_regdomain *custom_regd);
 
+/**
+ * regdom_intersect_wiphy_regd - do intersection on driver's regulatory domain
+ * @wiphy: the wireless device we want to process the intersected regulatory
+ *     domain on
+ *
+ * This function can be used on a driver's reg_notifier() when cfg80211's
+ * regulatory domain has been updated and a driver must follow nothing
+ * more than what was on its own driver regulatory domain. The driver must
+ * have previously called regulatory_hint() or regulatory_set_custom_rd().
+ * Note that the reg_notifier() is called with the cfg80211_drv_mutex already
+ * held.
+ */
+extern int regdom_intersect_wiphy_regd(struct wiphy *wiphy);
+
 #endif /* __NET_WIRELESS_H */
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index b05df36..88e8ff0 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -979,6 +979,21 @@ void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
 		wiphy->reg_notifier(wiphy, setby);
 }
 
+/* Does not call the reg_notifier() */
+int regdom_intersect_wiphy_regd(struct wiphy *wiphy)
+{
+	const struct ieee80211_regdomain *regd;
+	BUG_ON(!wiphy->regd);
+	regd = regdom_intersect(wiphy->regd, cfg80211_regdomain);
+	if (!regd)
+		return -EINVAL;
+	kfree(wiphy->regd);
+	wiphy->regd = regd;
+	regd_update_regulatory(wiphy);
+	return 0;
+}
+EXPORT_SYMBOL(regdom_intersect_wiphy_regd);
+
 static int reg_copy_regd(const struct ieee80211_regdomain **dst_regd,
 			 const struct ieee80211_regdomain *src_regd)
 {
-- 
1.6.1.rc3.51.g5832d

[PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain

[Luis R. Rodriguez]

A driver's reg_notfier() may want to inspect the currently set
regulatory domain.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/net/wireless.h |    3 +++
 net/wireless/reg.c     |    3 ++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/net/wireless.h b/include/net/wireless.h
index cb04e7b..4fd40a2 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -437,4 +437,7 @@ extern int regulatory_set_custom_rd(
  */
 extern int regdom_intersect_wiphy_regd(struct wiphy *wiphy);
 
+/* The wireless core regulatory domain */
+extern const struct ieee80211_regdomain *cfg80211_regdomain;
+
 #endif /* __NET_WIRELESS_H */
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 88e8ff0..ad38a9d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -89,7 +89,8 @@ static u32 supported_bandwidths[] = {
 /* Central wireless core regulatory domains, we only need two,
  * the current one and a world regulatory domain in case we have no
  * information to give us an alpha2 */
-static const struct ieee80211_regdomain *cfg80211_regdomain;
+const struct ieee80211_regdomain *cfg80211_regdomain;
+EXPORT_SYMBOL(cfg80211_regdomain);
 
 /* We use this as a place for the rd structure built from the
  * last parsed country IE to rest until CRDA gets back to us with
-- 
1.6.1.rc3.51.g5832d

[PATCH 08/12] cfg80211: export freq_reg_info()

[Luis R. Rodriguez]

This can be used by drivers on the reg_notifier()

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/net/wireless.h |   24 ++++++++++++++++++++++++
 net/wireless/reg.c     |   24 ++----------------------
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/include/net/wireless.h b/include/net/wireless.h
index 4fd40a2..5982b91 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -437,6 +437,30 @@ extern int regulatory_set_custom_rd(
  */
 extern int regdom_intersect_wiphy_regd(struct wiphy *wiphy);
 
+/**
+ * freq_reg_info - get regulatory information for the given frequency
+ * @wiphy: the wiphy for which we want to process this rule for
+ * @center_freq: Frequency in KHz for which we want regulatory information for
+ * @bandwidth: the bandwidth requirement you have in KHz, if you do not have one
+ * 	you can set this to 0. If this frequency is allowed we then set
+ * 	this value to the maximum allowed bandwidth.
+ * @reg_rule: the regulatory rule which we have for this frequency
+ *
+ * Use this function to get the regulatory rule for a specific frequency on
+ * a given wireless device. If the device has a specific regulatory domain
+ * it wants to follow we respect that unless a country IE has been received
+ * and processed already.
+ *
+ * Returns 0 if it was able to find a valid regulatory rule which does
+ * apply to the given center_freq otherwise it returns non-zero. It will
+ * also return -ERANGE if we determine the given center_freq does not even have
+ * a regulatory rule for a frequency range in the center_freq's band. See
+ * freq_in_rule_band() for our current definition of a band -- this is purely
+ * subjective and right now its 802.11 specific.
+ */
+extern int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
+			 const struct ieee80211_reg_rule **reg_rule);
+
 /* The wireless core regulatory domain */
 extern const struct ieee80211_regdomain *cfg80211_regdomain;
 
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index ad38a9d..7bc1ae8 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -797,28 +797,7 @@ static int reg_follow_driver_regd(struct wiphy *wiphy)
 	return false;
 }
 
-/**
- * freq_reg_info - get regulatory information for the given frequency
- * @wiphy: the wiphy for which we want to process this rule for
- * @center_freq: Frequency in KHz for which we want regulatory information for
- * @bandwidth: the bandwidth requirement you have in KHz, if you do not have one
- * 	you can set this to 0. If this frequency is allowed we then set
- * 	this value to the maximum allowed bandwidth.
- * @reg_rule: the regulatory rule which we have for this frequency
- *
- * Use this function to get the regulatory rule for a specific frequency on
- * a given wireless device. If the device has a specific regulatory domain
- * it wants to follow we respect that unless a country IE has been received
- * and processed already.
- *
- * Returns 0 if it was able to find a valid regulatory rule which does
- * apply to the given center_freq otherwise it returns non-zero. It will
- * also return -ERANGE if we determine the given center_freq does not even have
- * a regulatory rule for a frequency range in the center_freq's band. See
- * freq_in_rule_band() for our current definition of a band -- this is purely
- * subjective and right now its 802.11 specific.
- */
-static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
+int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
 			 const struct ieee80211_reg_rule **reg_rule)
 {
 	int i;
@@ -863,6 +842,7 @@ static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
 
 	return !max_bandwidth;
 }
+EXPORT_SYMBOL(freq_reg_info);
 
 static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 			   unsigned int chan_idx)
-- 
1.6.1.rc3.51.g5832d

[PATCH 09/12] cfg80211: Fix sanity check on 5 GHz when processing country IE

[Luis R. Rodriguez]

This fixes two issues with the sanity check loop when processing
the country IE:

1. Do not use frequency for the current subband channel check,
   this was a big fat typo.
2. Apply the 5 GHz 4-channel steps when considering max channel
   on each subband as was done with a recent patch.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/wireless/reg.c |   30 +++++++++++++++++++-----------
 1 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 7bc1ae8..12a547a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -499,6 +499,7 @@ static struct ieee80211_regdomain *country_ie_2_rd(
 	 * calculate the number of reg rules we will need. We will need one
 	 * for each channel subband */
 	while (country_ie_len >= 3) {
+		int end_channel = 0;
 		struct ieee80211_country_ie_triplet *triplet =
 			(struct ieee80211_country_ie_triplet *) country_ie;
 		int cur_sub_max_channel = 0, cur_channel = 0;
@@ -510,9 +511,25 @@ static struct ieee80211_regdomain *country_ie_2_rd(
 			continue;
 		}
 
+		/* 2 GHz */
+		if (triplet->chans.first_channel <= 14)
+			end_channel = triplet->chans.first_channel +
+				triplet->chans.num_channels;
+		else
+			/*
+			 * 5 GHz -- For example in country IEs if the first
+			 * channel given is 36 and the number of channels is 4
+			 * then the individual channel numbers defined for the
+			 * 5 GHz PHY by these parameters are: 36, 40, 44, and 48
+			 * and not 36, 37, 38, 39.
+			 *
+			 * See: http://tinyurl.com/11d-clarification
+			 */
+			end_channel =  triplet->chans.first_channel +
+				(4 * (triplet->chans.num_channels - 1));
+
 		cur_channel = triplet->chans.first_channel;
-		cur_sub_max_channel = ieee80211_channel_to_frequency(
-			cur_channel + triplet->chans.num_channels);
+		cur_sub_max_channel = end_channel;
 
 		/* Basic sanity check */
 		if (cur_sub_max_channel < cur_channel)
@@ -591,15 +608,6 @@ static struct ieee80211_regdomain *country_ie_2_rd(
 			end_channel = triplet->chans.first_channel +
 				triplet->chans.num_channels;
 		else
-			/*
-			 * 5 GHz -- For example in country IEs if the first
-			 * channel given is 36 and the number of channels is 4
-			 * then the individual channel numbers defined for the
-			 * 5 GHz PHY by these parameters are: 36, 40, 44, and 48
-			 * and not 36, 37, 38, 39.
-			 *
-			 * See: http://tinyurl.com/11d-clarification
-			 */
 			end_channel =  triplet->chans.first_channel +
 				(4 * (triplet->chans.num_channels - 1));
 
-- 
1.6.1.rc3.51.g5832d

[PATCH 10/12] cfg80211: process user requests only after previous user/driver/core requests

[Luis R. Rodriguez]

This prevents user regulatory changes to be considered prior to previous
pending user, core or driver requests which have not be applied.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/wireless/reg.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 12a547a..460411d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1082,6 +1082,16 @@ static int ignore_request(struct wiphy *wiphy, enum reg_set_by set_by,
 		if (last_request->initiator == REGDOM_SET_BY_USER &&
 			  last_request->intersect)
 			return -EOPNOTSUPP;
+		if (last_request->initiator == REGDOM_SET_BY_CORE ||
+		    last_request->initiator == REGDOM_SET_BY_DRIVER ||
+		    last_request->initiator == REGDOM_SET_BY_USER) {
+			if (alpha2_equal(last_request->alpha2,
+			    cfg80211_regdomain->alpha2))
+				return 0;
+			else
+				return -EAGAIN;
+		}
+
 		return 0;
 	}
 
-- 
1.6.1.rc3.51.g5832d

[PATCH 11/12] mac80211: allow mac80211 drivers to get to driver priv from wiphy

[Luis R. Rodriguez]

If a driver is given a wiphy and it wants to get to its private
mac80211 driver area it can use mac80211_wiphy_driver_priv(). The
wiphy_priv() is already being used internally by mac80211 and drivers
should not use this. This can be helpful a drivers reg_notifier().

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/net/mac80211.h |   11 +++++++++++
 net/mac80211/util.c    |    9 +++++++++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 00f7ec0..b73c379 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -966,6 +966,17 @@ struct ieee80211_hw {
 };
 
 /**
+ * mac80211_wiphy_driver_priv - return a mac80211 driver's priv from a wiphy
+ *
+ * @wiphy: the &struct wiphy which we want to query
+ *
+ * mac80211 drivers can use this instead of wiphy_priv() to get to their
+ * driver's private area. wiphy_priv() is used internally by mac80211 for
+ * its own private area and should not be used by mac80211 drivers.
+ */
+void *mac80211_wiphy_driver_priv(struct wiphy *wiphy);
+
+/**
  * SET_IEEE80211_DEV - set device for 802.11 hardware
  *
  * @hw: the &struct ieee80211_hw to set the device for
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 963e047..81d2cbb 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -41,6 +41,15 @@ const unsigned char rfc1042_header[] __aligned(2) =
 const unsigned char bridge_tunnel_header[] __aligned(2) =
 	{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
 
+void *mac80211_wiphy_driver_priv(struct wiphy *wiphy)
+{
+	struct ieee80211_local *local;
+	BUG_ON(!wiphy);
+
+	local = wiphy_priv(wiphy);
+	return local->hw.priv;
+}
+EXPORT_SYMBOL(mac80211_wiphy_driver_priv);
 
 u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
 			enum nl80211_iftype type)
-- 
1.6.1.rc3.51.g5832d

[PATCH 12/12] cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

[Luis R. Rodriguez]

This removal was scheduled for 2.6.29 but we decided to
keep it around a bit longer. Now that we are on road to
2.6.30 lets remove it.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 Documentation/feature-removal-schedule.txt |   18 ---
 net/wireless/Kconfig                       |   46 +++------
 net/wireless/reg.c                         |  161 +++-------------------------
 3 files changed, 26 insertions(+), 199 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index ac98851..f178d8b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -6,24 +6,6 @@ be removed from this file.
 
 ---------------------------
 
-What:	old static regulatory information and ieee80211_regdom module parameter
-When:	2.6.29
-Why:	The old regulatory infrastructure has been replaced with a new one
-	which does not require statically defined regulatory domains. We do
-	not want to keep static regulatory domains in the kernel due to the
-	the dynamic nature of regulatory law and localization. We kept around
-	the old static definitions for the regulatory domains of:
-		* US
-		* JP
-		* EU
-	and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
-	set. We also kept around the ieee80211_regdom module parameter in case
-	some applications were relying on it. Changing regulatory domains
-	can now be done instead by using nl80211, as is done with iw.
-Who:	Luis R. Rodriguez <lrodriguez@atheros.com>
-
----------------------------
-
 What:	dev->power.power_state
 When:	July 2007
 Why:	Broken design for runtime control over driver power states, confusing
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index e28e2b8..bc00782 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -1,5 +1,18 @@
 config CFG80211
         tristate "Improved wireless configuration API"
+	---help---
+	  cfg80211 is the new wireless driver framework. If you have a
+	  modern wireless card you want to enable this option.
+
+	  cfg80211's regulatory framework requires a userspace application
+	  which has the database of regulatory information (CRDA). Setting
+	  of regulatory domains can be done by drivers, or the wireless core
+	  based on country information elements. Users can also use userspace
+	  applications like iw or wpa_supplicant to help compliance further.
+
+	  For more information see:
+
+	  http://wireless.kernel.org/en/developers/Regulatory/
 
 config CFG80211_REG_DEBUG
 	bool "cfg80211 regulatory debugging"
@@ -23,39 +36,6 @@ config NL80211
 
 	  If unsure, say Y.
 
-config WIRELESS_OLD_REGULATORY
-	bool "Old wireless static regulatory definitions"
-	default y
-	---help---
-	  This option enables the old static regulatory information
-	  and uses it within the new framework. This is available
-	  temporarily as an option to help prevent immediate issues
-	  due to the switch to the new regulatory framework which
-	  does require a new userspace application which has the
-	  database of regulatory information (CRDA) and another for
-	  setting regulatory domains (iw).
-
-	  For more information see:
-
-	  http://wireless.kernel.org/en/developers/Regulatory/CRDA
-	  http://wireless.kernel.org/en/users/Documentation/iw
-
-	  It is important to note though that if you *do* have CRDA present
-	  and if this option is enabled CRDA *will* be called to update the
-	  regulatory domain (for US and JP only). Support for letting the user
-	  set the regulatory domain through iw is also supported. This option
-	  mainly exists to leave around for a kernel release some old static
-	  regulatory domains that were defined and to keep around the old
-	  ieee80211_regdom module parameter. This is being phased out and you
-	  should stop using them ASAP.
-
-	  Note: You will need CRDA if you want 802.11d support
-
-	  Say Y unless you have installed a new userspace application.
-	  Also say Y if have one currently depending on the ieee80211_regdom
-	  module parameter and cannot port it to use the new userspace
-	  interfaces.
-
 config WIRELESS_EXT
 	bool "Wireless extensions"
 	default n
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 460411d..1133a38 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -111,103 +111,6 @@ static const struct ieee80211_regdomain world_regdom = {
 static const struct ieee80211_regdomain *cfg80211_world_regdom =
 	&world_regdom;
 
-#ifdef CONFIG_WIRELESS_OLD_REGULATORY
-static char *ieee80211_regdom = "US";
-module_param(ieee80211_regdom, charp, 0444);
-MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain code");
-
-/* We assume 40 MHz bandwidth for the old regulatory work.
- * We make emphasis we are using the exact same frequencies
- * as before */
-
-static const struct ieee80211_regdomain us_regdom = {
-	.n_reg_rules = 6,
-	.alpha2 =  "US",
-	.reg_rules = {
-		/* IEEE 802.11b/g, channels 1..11 */
-		REG_RULE(2412-10, 2462+10, 40, 6, 27, 0),
-		/* IEEE 802.11a, channel 36 */
-		REG_RULE(5180-10, 5180+10, 40, 6, 23, 0),
-		/* IEEE 802.11a, channel 40 */
-		REG_RULE(5200-10, 5200+10, 40, 6, 23, 0),
-		/* IEEE 802.11a, channel 44 */
-		REG_RULE(5220-10, 5220+10, 40, 6, 23, 0),
-		/* IEEE 802.11a, channels 48..64 */
-		REG_RULE(5240-10, 5320+10, 40, 6, 23, 0),
-		/* IEEE 802.11a, channels 149..165, outdoor */
-		REG_RULE(5745-10, 5825+10, 40, 6, 30, 0),
-	}
-};
-
-static const struct ieee80211_regdomain jp_regdom = {
-	.n_reg_rules = 3,
-	.alpha2 =  "JP",
-	.reg_rules = {
-		/* IEEE 802.11b/g, channels 1..14 */
-		REG_RULE(2412-10, 2484+10, 40, 6, 20, 0),
-		/* IEEE 802.11a, channels 34..48 */
-		REG_RULE(5170-10, 5240+10, 40, 6, 20,
-			NL80211_RRF_PASSIVE_SCAN),
-		/* IEEE 802.11a, channels 52..64 */
-		REG_RULE(5260-10, 5320+10, 40, 6, 20,
-			NL80211_RRF_NO_IBSS |
-			NL80211_RRF_DFS),
-	}
-};
-
-static const struct ieee80211_regdomain eu_regdom = {
-	.n_reg_rules = 6,
-	/* This alpha2 is bogus, we leave it here just for stupid
-	 * backward compatibility */
-	.alpha2 =  "EU",
-	.reg_rules = {
-		/* IEEE 802.11b/g, channels 1..13 */
-		REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
-		/* IEEE 802.11a, channel 36 */
-		REG_RULE(5180-10, 5180+10, 40, 6, 23,
-			NL80211_RRF_PASSIVE_SCAN),
-		/* IEEE 802.11a, channel 40 */
-		REG_RULE(5200-10, 5200+10, 40, 6, 23,
-			NL80211_RRF_PASSIVE_SCAN),
-		/* IEEE 802.11a, channel 44 */
-		REG_RULE(5220-10, 5220+10, 40, 6, 23,
-			NL80211_RRF_PASSIVE_SCAN),
-		/* IEEE 802.11a, channels 48..64 */
-		REG_RULE(5240-10, 5320+10, 40, 6, 20,
-			NL80211_RRF_NO_IBSS |
-			NL80211_RRF_DFS),
-		/* IEEE 802.11a, channels 100..140 */
-		REG_RULE(5500-10, 5700+10, 40, 6, 30,
-			NL80211_RRF_NO_IBSS |
-			NL80211_RRF_DFS),
-	}
-};
-
-static const struct ieee80211_regdomain *static_regdom(char *alpha2)
-{
-	if (alpha2[0] == 'U' && alpha2[1] == 'S')
-		return &us_regdom;
-	if (alpha2[0] == 'J' && alpha2[1] == 'P')
-		return &jp_regdom;
-	if (alpha2[0] == 'E' && alpha2[1] == 'U')
-		return &eu_regdom;
-	/* Default, as per the old rules */
-	return &us_regdom;
-}
-
-static bool is_old_static_regdom(const struct ieee80211_regdomain *rd)
-{
-	if (rd == &us_regdom || rd == &jp_regdom || rd == &eu_regdom)
-		return true;
-	return false;
-}
-#else
-static inline bool is_old_static_regdom(const struct ieee80211_regdomain *rd)
-{
-	return false;
-}
-#endif
-
 static void reset_regdomains(void)
 {
 	/* avoid freeing static information or freeing something twice */
@@ -217,8 +120,6 @@ static void reset_regdomains(void)
 		cfg80211_world_regdom = NULL;
 	if (cfg80211_regdomain == &world_regdom)
 		cfg80211_regdomain = NULL;
-	if (is_old_static_regdom(cfg80211_regdomain))
-		cfg80211_regdomain = NULL;
 
 	kfree(cfg80211_regdomain);
 	kfree(cfg80211_world_regdom);
@@ -1152,16 +1053,6 @@ new_request:
 	if (r < 0)
 		return r;
 
-	/*
-	 * Note: When CONFIG_WIRELESS_OLD_REGULATORY is enabled
-	 * AND if CRDA is NOT present nothing will happen, if someone
-	 * wants to bother with 11d with OLD_REG you can add a timer.
-	 * If after x amount of time nothing happens you can call:
-	 *
-	 * return set_regdom(country_ie_regdomain);
-	 *
-	 * to intersect with the static rd
-	 */
 	return call_crda(alpha2);
 }
 
@@ -1416,16 +1307,11 @@ static int __set_regdom(const struct ieee80211_regdomain *rd)
 	if (!last_request)
 		return -EINVAL;
 
-	/* Lets only bother proceeding on the same alpha2 if the current
-	 * rd is non static (it means CRDA was present and was used last)
-	 * and the pending request came in from a country IE */
-	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE) {
-		/* If someone else asked us to change the rd lets only bother
-		 * checking if the alpha2 changes if CRDA was already called */
-		if (!is_old_static_regdom(cfg80211_regdomain) &&
-		    !regdom_changed(rd->alpha2))
-			return -EINVAL;
-	}
+	/* Lets only bother proceeding on the same alpha2 if the
+	 * pending request came in from a country IE */
+	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE &&
+	    !regdom_changed(rd->alpha2))
+		return -EINVAL;
 
 	wiphy = last_request->wiphy;
 
@@ -1497,24 +1383,18 @@ static int __set_regdom(const struct ieee80211_regdomain *rd)
 	 */
 
 	BUG_ON(!country_ie_regdomain);
+	BUG_ON(rd == country_ie_regdomain);
 
-	if (rd != country_ie_regdomain) {
-		/* Intersect what CRDA returned and our what we
-		 * had built from the Country IE received */
+	/* Intersect what CRDA returned and our what we
+	 * had built from the Country IE received */
 
-		intersected_rd = regdom_intersect(rd, country_ie_regdomain);
+	intersected_rd = regdom_intersect(rd, country_ie_regdomain);
 
-		reg_country_ie_process_debug(rd, country_ie_regdomain,
-			intersected_rd);
+	reg_country_ie_process_debug(rd, country_ie_regdomain,
+		intersected_rd);
 
-		kfree(country_ie_regdomain);
-		country_ie_regdomain = NULL;
-	} else {
-		/* This would happen when CRDA was not present and
-		 * OLD_REGULATORY was enabled. We intersect our Country
-		 * IE rd and what was set on cfg80211 originally */
-		intersected_rd = regdom_intersect(rd, cfg80211_regdomain);
-	}
+	kfree(country_ie_regdomain);
+	country_ie_regdomain = NULL;
 
 	if (!intersected_rd)
 		return -EINVAL;
@@ -1583,19 +1463,6 @@ int regulatory_init(void)
 	if (IS_ERR(reg_pdev))
 		return PTR_ERR(reg_pdev);
 
-#ifdef CONFIG_WIRELESS_OLD_REGULATORY
-	cfg80211_regdomain = static_regdom(ieee80211_regdom);
-
-	printk(KERN_INFO "cfg80211: Using static regulatory domain info\n");
-	print_regdomain_info(cfg80211_regdomain);
-	/* The old code still requests for a new regdomain and if
-	 * you have CRDA you get it updated, otherwise you get
-	 * stuck with the static values. We ignore "EU" code as
-	 * that is not a valid ISO / IEC 3166 alpha2 */
-	if (ieee80211_regdom[0] != 'E' || ieee80211_regdom[1] != 'U')
-		err = __regulatory_hint(NULL, REGDOM_SET_BY_CORE,
-					ieee80211_regdom, 0, ENVIRON_ANY);
-#else
 	cfg80211_regdomain = cfg80211_world_regdom;
 
 	err = __regulatory_hint(NULL, REGDOM_SET_BY_CORE, "00", 0, ENVIRON_ANY);
@@ -1603,8 +1470,6 @@ int regulatory_init(void)
 		printk(KERN_ERR "cfg80211: calling CRDA failed - "
 		       "unable to update world regulatory domain, "
 		       "using static definition\n");
-#endif
-
 	return 0;
 }
 
-- 
1.6.1.rc3.51.g5832d

Re: [PATCH 12/12] cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> This removal was scheduled for 2.6.29 but we decided to
> keep it around a bit longer. Now that we are on road to
> 2.6.30 lets remove it.

Don't like this much, it's not really biting us (yet) to have this code
around still.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 12/12] cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

[Luis R. Rodriguez]

On Tue, Jan 13, 2009 at 2:50 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
>> This removal was scheduled for 2.6.29 but we decided to
>> keep it around a bit longer. Now that we are on road to
>> 2.6.30 lets remove it.
>
> Don't like this much, it's not really biting us (yet) to have this code
> around still.

It means double testing, I was going to test all the work in this
series with this option but I figured it'd be better to move on.

  Luis

Re: [PATCH 12/12] cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Tue, 2009-01-13 at 15:00 -0800, Luis R. Rodriguez wrote:

> > Don't like this much, it's not really biting us (yet) to have this code
> > around still.
> 
> It means double testing, I was going to test all the work in this
> series with this option but I figured it'd be better to move on.

I don't think it matters much since the impact of this code is now
fairly small, we simply start with a different initial setup which can
always happen with crda too.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 11/12] mac80211: allow mac80211 drivers to get to driver priv from wiphy

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> If a driver is given a wiphy and it wants to get to its private
> mac80211 driver area it can use mac80211_wiphy_driver_priv(). The
> wiphy_priv() is already being used internally by mac80211 and drivers
> should not use this. This can be helpful a drivers reg_notifier().

> + * mac80211_wiphy_driver_priv - return a mac80211 driver's priv from a wiphy
> + *
> + * @wiphy: the &struct wiphy which we want to query
> + *
> + * mac80211 drivers can use this instead of wiphy_priv() to get to their
> + * driver's private area. wiphy_priv() is used internally by mac80211 for
> + * its own private area and should not be used by mac80211 drivers.
> + */
> +void *mac80211_wiphy_driver_priv(struct wiphy *wiphy);

I think I'd prefer to have this return the hw struct, and the drivers
can dereference to priv themselves.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> A driver's reg_notfier() may want to inspect the currently set
> regulatory domain.

> +const struct ieee80211_regdomain *cfg80211_regdomain;
> +EXPORT_SYMBOL(cfg80211_regdomain);

Can't we just pass it to the notifier instead of exporting it?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain

[Luis R. Rodriguez]

On Tue, Jan 13, 2009 at 02:46:59PM -0800, Johannes Berg wrote:
> On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> > A driver's reg_notfier() may want to inspect the currently set
> > regulatory domain.
> 
> > +const struct ieee80211_regdomain *cfg80211_regdomain;
> > +EXPORT_SYMBOL(cfg80211_regdomain);
> 
> Can't we just pass it to the notifier instead of exporting it?

I as thinking about that too, sure, either or is fine. Any preference?

  Luis

Re: [PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Tue, 2009-01-13 at 14:51 -0800, Luis R. Rodriguez wrote:
> On Tue, Jan 13, 2009 at 02:46:59PM -0800, Johannes Berg wrote:
> > On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> > > A driver's reg_notfier() may want to inspect the currently set
> > > regulatory domain.
> > 
> > > +const struct ieee80211_regdomain *cfg80211_regdomain;
> > > +EXPORT_SYMBOL(cfg80211_regdomain);
> > 
> > Can't we just pass it to the notifier instead of exporting it?
> 
> I as thinking about that too, sure, either or is fine. Any preference?

I prefer not exporting it. That makes it more local, and saves the
export. Not that I see why we need it at all? You're not using it, so
let's not do anything with it until we need it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain

[Luis R. Rodriguez]

On Tue, Jan 13, 2009 at 2:53 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2009-01-13 at 14:51 -0800, Luis R. Rodriguez wrote:
>> On Tue, Jan 13, 2009 at 02:46:59PM -0800, Johannes Berg wrote:
>> > On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
>> > > A driver's reg_notfier() may want to inspect the currently set
>> > > regulatory domain.
>> >
>> > > +const struct ieee80211_regdomain *cfg80211_regdomain;
>> > > +EXPORT_SYMBOL(cfg80211_regdomain);
>> >
>> > Can't we just pass it to the notifier instead of exporting it?
>>
>> I as thinking about that too, sure, either or is fine. Any preference?
>
> I prefer not exporting it. That makes it more local, and saves the
> export. Not that I see why we need it at all? You're not using it, so
> let's not do anything with it until we need it.

Actually -- you're right, I thought we needed in the reg_notifier()
but freq_reg_info() was used instead. Hmm, brain fart I guess. Good
catch.

  Luis

Re: [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> This series contains a few fixes for cfg80211 such as another
> fix for parsing country IEs, but mostly contains work to help
> drivers build a more useful reg_notifier(). While at it we remove
> the CONFIG_WIRELESS_OLD_REGULATORY as we are now on road to 2.6.30.
> 
> Luis R. Rodriguez (12):
>   cfg80211: print correct intersected regulatory domain
>   cfg80211: add helper to indicate when to follow the driver regd
>   cfg80211: add option for wiphys to disregard country IEs
>   cfg80211: split wiphy_update_regulatory() in two
>   cfg80211: add regulatory_set_custom_rd()
>   cfg80211: add regdom_intersect_wiphy_regd()
>   cfg80211: allow driver read access to cfg80211_regdomain
>   cfg80211: export freq_reg_info()
>   cfg80211: Fix sanity check on 5 GHz when processing country IE
>   cfg80211: process user requests only after previous user/driver/core
>     requests
>   mac80211: allow mac80211 drivers to get to driver priv from wiphy
>   cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

I think this series is pretty much overkill. While I'd like you to
finish work on this (you know why), I think you should go back and
describe what you're trying to achieve.

It seems to me that you're trying to achieve two things:
 1) have ath9k have its own world regdomain
 2) restrict ath9k to the channels it has calibration data for

Am I totally off base?

For point (1), I'm not sure how you're doing that right now, but (2) you
should not do via the regulatory code and the notifier but rather by not
registering those channels to start with, or setting the disabled flag
before registration if that's easier.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()

[Luis R. Rodriguez]

On Tue, Jan 13, 2009 at 03:00:21PM -0800, Johannes Berg wrote:
> On Tue, 2009-01-13 at 11:57 -0800, Luis R. Rodriguez wrote:
> > This series contains a few fixes for cfg80211 such as another
> > fix for parsing country IEs, but mostly contains work to help
> > drivers build a more useful reg_notifier(). While at it we remove
> > the CONFIG_WIRELESS_OLD_REGULATORY as we are now on road to 2.6.30.
> > 
> > Luis R. Rodriguez (12):
> >   cfg80211: print correct intersected regulatory domain
> >   cfg80211: add helper to indicate when to follow the driver regd
> >   cfg80211: add option for wiphys to disregard country IEs
> >   cfg80211: split wiphy_update_regulatory() in two
> >   cfg80211: add regulatory_set_custom_rd()
> >   cfg80211: add regdom_intersect_wiphy_regd()
> >   cfg80211: allow driver read access to cfg80211_regdomain
> >   cfg80211: export freq_reg_info()
> >   cfg80211: Fix sanity check on 5 GHz when processing country IE
> >   cfg80211: process user requests only after previous user/driver/core
> >     requests
> >   mac80211: allow mac80211 drivers to get to driver priv from wiphy
> >   cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY
> 
> I think this series is pretty much overkill. While I'd like you to
> finish work on this (you know why), I think you should go back and
> describe what you're trying to achieve.
> 
> It seems to me that you're trying to achieve two things:
>  1) have ath9k have its own world regdomain
>  2) restrict ath9k to the channels it has calibration data for
> 
> Am I totally off base?

Well its more of trusting CRDA for country regulatory data on ath9k, and of
allowing ath9k to use its own custom regulatory domains. The calibration data
just follows the regulatory domains and varies through time as updates go into
the wireless-regdb.

> For point (1), I'm not sure how you're doing that right now, but 

It is done via add regulatory_set_custom_rd() which copies the static
regdomain into wiphy->regd (handled then by cfg80211).

> (2) you
> should not do via the regulatory code and the notifier but rather by not
> registering those channels to start with

I did a lot of this work because you had opposed to allow drivers dynamically register
their channels. The size of the code also increases considerably by using static set of
channels for each custom regulatory domain, its possible though.

>, or setting the disabled flag
> before registration if that's easier.

You'll still need some sort of table. Either way -- all these are options of how to
accomplish the same task. I did this as part of cfg80211 as I figured it could be
used by other drivers.

  Luis

Re: [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On Tue, 2009-01-13 at 15:17 -0800, Luis R. Rodriguez wrote:
> > (2) you
> > should not do via the regulatory code and the notifier but rather by not
> > registering those channels to start with
> 
> I did a lot of this work because you had opposed to allow drivers dynamically register
> their channels. 

I think we may have had some miscommunication here? I didn't like
registering the channels dynamically with new calls, but I certainly
don't care how you arrive at your channel array, you can kmalloc it if
you want.

> The size of the code also increases considerably by using static set of
> channels for each custom regulatory domain, its possible though.

You don't have to.

> >, or setting the disabled flag
> > before registration if that's easier.
> 
> You'll still need some sort of table. Either way -- all these are options of how to
> accomplish the same task. I did this as part of cfg80211 as I figured it could be
> used by other drivers.

In what form do you have this data? Is it "valid 2412-2472 and 4950-5250
MHz"? If so, can we just have a function that marks all channel that
would fall outside these ranges as invalid, and you call that function
with a specific band and channel before registering your wiphy?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()

[Luis R. Rodriguez]

On Tue, Jan 13, 2009 at 3:23 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2009-01-13 at 15:17 -0800, Luis R. Rodriguez wrote:
>> > (2) you
>> > should not do via the regulatory code and the notifier but rather by not
>> > registering those channels to start with
>>
>> I did a lot of this work because you had opposed to allow drivers dynamically register
>> their channels.
>
> I think we may have had some miscommunication here? I didn't like
> registering the channels dynamically with new calls, but I certainly
> don't care how you arrive at your channel array, you can kmalloc it if
> you want.

It seems like it, anyway I'd prefer we use a static set of channels.

>> The size of the code also increases considerably by using static set of
>> channels for each custom regulatory domain, its possible though.
>
> You don't have to.
>
>> >, or setting the disabled flag
>> > before registration if that's easier.
>>
>> You'll still need some sort of table. Either way -- all these are options of how to
>> accomplish the same task. I did this as part of cfg80211 as I figured it could be
>> used by other drivers.
>
> In what form do you have this data?

I posted the respective ath9k patch.

> Is it "valid 2412-2472 and 4950-5250
> MHz"?

Yes, with flags, it consists of 5 static ieee80211_regdomain structs
and a helper to change flags where required.

> If so, can we just have a function that marks all channel that
> would fall outside these ranges as invalid, and you call that function
> with a specific band and channel before registering your wiphy?

Yeah that would work too. Only other thing I can think about is that
of us requiring custom preferences on the regulatory flags when on the
world regulatory domains. For now we have only one such custom rule:

- Do not allow adhoc on 5 GHz unless specified by country IE -- only
when on some specific world regulatory domains. The other regdomains
must follow the world regdomain / country rule.

The active / passive scan stuff is dealt with in similar with in the
patch I posted but that's just to condense the number of world
regulatory domain structs to 5. I suppose the above custom rule I
mentioned could just be dealt with on the reg_notifier(). Hmm -- yeah
I like your suggestion.

  Luis