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

[PATCH 00/13] 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.

This v2 of this series changes the way we deal with custom regulatory
domains and require them to be passed to cfg80211 prior to wiphy
registration. The trick and emphasis here is to use the channel orig_*
values to ensures they are respected. Another nice advantage of this
approach is after a regulatory_hint or a custom regulatory hint a user
regulatory_hint() will only be applied against the driver's regulatory
domain, not the previous user regulatory domain. This should allow
users who suspend/resume to travel and change regulatory domains manually
to help compliance without loosing channels based on previous locations.

Thanks to Johannes for his pointers.

Luis R. Rodriguez (13):
  cfg80211: print correct intersected regulatory domain
  cfg80211: add option for wiphys to disregard country IEs
  cfg80211: add wiphy_apply_custom_regulatory()
  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
  cfg80211: only export disable flag on channel disablement
  cfg80211: save original values on regulatory hints
  cfg80211: rename fw_handles_regulatory to custom_regulatory
  cfg80211: remove check for last_request on ignore_reg_update()
  cfg80211: move check for ignore_reg_update() on
    wiphy_update_regulatory()
  mac80211: allow mac80211 drivers to get to struct ieee80211_hw from
    wiphy
  cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY

 Documentation/feature-removal-schedule.txt  |   18 --
 drivers/net/wireless/iwlwifi/iwl-core.c     |    2 +-
 drivers/net/wireless/iwlwifi/iwl3945-base.c |    2 +-
 include/net/cfg80211.h                      |    4 +
 include/net/mac80211.h                      |   13 +
 include/net/wireless.h                      |   51 ++++-
 net/mac80211/util.c                         |    9 +
 net/wireless/Kconfig                        |   46 +---
 net/wireless/nl80211.c                      |    5 -
 net/wireless/reg.c                          |  354 ++++++++++++---------------
 10 files changed, 248 insertions(+), 256 deletions(-)

[PATCH 01/13] 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/13] 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     |   19 +++++++++++++++++--
 2 files changed, 21 insertions(+), 2 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 ec8b3d9..01da946 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -782,6 +782,20 @@ static u32 map_regdom_flags(u32 rd_flags)
 	return channel_flags;
 }
 
+/* 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 (!wiphy->regd)
+		return false;
+	if (wiphy->ignore_country_ies)
+		return true;
+	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE)
+		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
@@ -883,7 +897,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 "
@@ -895,7 +909,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 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Luis R. Rodriguez]

This adds wiphy_apply_custom_regulatory() to be used by drivers
prior to wiphy registration to apply a custom regulatory domain.
This can be used by drivers that do not have a direct 1-1 mapping
between a regulatory domain and a country.

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

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index df78abc..6bab7a1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -338,6 +338,9 @@ struct bss_parameters {
 
 /**
  * enum reg_set_by - Indicates who is trying to set the regulatory domain
+ * @REGDOM_SET_BY_PROBE: regulatory domain applied came prior to wiphy
+ * 	registration by the driver itself using some custom regulatory
+ * 	information.
  * @REGDOM_SET_BY_INIT: regulatory domain was set by initialization. We will be
  * 	using a static world regulatory domain by default.
  * @REGDOM_SET_BY_CORE: Core queried CRDA for a dynamic world regulatory domain.
@@ -350,6 +353,7 @@ struct bss_parameters {
  *	should consider.
  */
 enum reg_set_by {
+	REGDOM_SET_BY_PROBE,
 	REGDOM_SET_BY_INIT,
 	REGDOM_SET_BY_CORE,
 	REGDOM_SET_BY_USER,
diff --git a/include/net/wireless.h b/include/net/wireless.h
index ea89958..b724519 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -405,4 +405,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);
+
+/**
+ * wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
+ * @wiphy: the wireless device we want to process the regulatory domain on
+ * @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. This routine must be called prior to wiphy registration. The
+ * custom regulatory domain will be trusted completely and as such previous
+ * default channel settings will be disregarded. If no rule is found for a
+ * channel on the regulatory domain the channel will be disabled.
+ */
+extern void wiphy_apply_custom_regulatory(
+	struct wiphy *wiphy,
+	const struct ieee80211_regdomain *regd);
+
 #endif /* __NET_WIRELESS_H */
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 01da946..4793d22 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -796,36 +796,17 @@ 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,
-			 const struct ieee80211_reg_rule **reg_rule)
+static int freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq,
+		       u32 *bandwidth,
+		       const struct ieee80211_reg_rule **reg_rule,
+		       const struct ieee80211_regdomain *custom_regd)
 {
 	int i;
 	bool band_rule_found = false;
 	const struct ieee80211_regdomain *regd;
 	u32 max_bandwidth = 0;
 
-	regd = cfg80211_regdomain;
+	regd = custom_regd ? custom_regd : cfg80211_regdomain;
 
 	/* Follow the driver's regulatory domain, if present, unless a country
 	 * IE has been processed */
@@ -866,6 +847,34 @@ static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
 	return !max_bandwidth;
 }
 
+/**
+ * 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,
+			 const struct ieee80211_reg_rule **reg_rule)
+{
+	return freq_reg_info_regd(wiphy, center_freq,
+		bandwidth, reg_rule, NULL);
+}
+
 static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 			   unsigned int chan_idx)
 {
@@ -935,6 +944,39 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 		chan->max_power = (int) MBM_TO_DBM(power_rule->max_eirp);
 }
 
+static void handle_channel_custom(struct wiphy *wiphy,
+				  enum ieee80211_band band,
+				  unsigned int chan_idx,
+				  const struct ieee80211_regdomain *regd)
+{
+	int r;
+	u32 max_bandwidth = 0;
+	const struct ieee80211_reg_rule *reg_rule = NULL;
+	const struct ieee80211_power_rule *power_rule = NULL;
+	struct ieee80211_supported_band *sband;
+	struct ieee80211_channel *chan;
+
+	sband = wiphy->bands[band];
+	BUG_ON(chan_idx >= sband->n_channels);
+	chan = &sband->channels[chan_idx];
+
+	r = freq_reg_info_regd(wiphy, MHZ_TO_KHZ(chan->center_freq),
+		&max_bandwidth, &reg_rule, regd);
+
+	if (r) {
+		chan->flags = IEEE80211_CHAN_DISABLED;
+		return;
+	}
+
+	power_rule = &reg_rule->power_rule;
+
+	chan->flags |= map_regdom_flags(reg_rule->flags);
+	chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain);
+	chan->max_bandwidth = KHZ_TO_MHZ(max_bandwidth);
+	chan->max_power = (int) MBM_TO_DBM(power_rule->max_eirp);
+}
+
+
 static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
 {
 	unsigned int i;
@@ -947,6 +989,19 @@ static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
 		handle_channel(wiphy, band, i);
 }
 
+static void handle_band_custom(struct wiphy *wiphy, enum ieee80211_band band,
+			       const struct ieee80211_regdomain *regd)
+{
+	unsigned int i;
+	struct ieee80211_supported_band *sband;
+
+	BUG_ON(!wiphy->bands[band]);
+	sband = wiphy->bands[band];
+
+	for (i = 0; i < sband->n_channels; i++)
+		handle_channel_custom(wiphy, band, i, regd);
+}
+
 static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
 {
 	if (!last_request)
@@ -977,6 +1032,20 @@ void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
 		wiphy->reg_notifier(wiphy, setby);
 }
 
+/* Used by drivers prior to wiphy registration */
+void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
+				   const struct ieee80211_regdomain *regd)
+{
+	enum ieee80211_band band;
+	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
+		if (wiphy->bands[band])
+			handle_band_custom(wiphy, band, regd);
+	}
+	if (wiphy->reg_notifier)
+		wiphy->reg_notifier(wiphy, REGDOM_SET_BY_PROBE);
+}
+EXPORT_SYMBOL(wiphy_apply_custom_regulatory);
+
 static int reg_copy_regd(const struct ieee80211_regdomain **dst_regd,
 			 const struct ieee80211_regdomain *src_regd)
 {
@@ -1015,6 +1084,9 @@ static int ignore_request(struct wiphy *wiphy, enum reg_set_by set_by,
 		return 0;
 
 	switch (set_by) {
+	case REGDOM_SET_BY_PROBE:
+		BUG_ON(1);
+		return -EINVAL;
 	case REGDOM_SET_BY_INIT:
 		return -EINVAL;
 	case REGDOM_SET_BY_CORE:
-- 
1.6.1.rc3.51.g5832d

[PATCH 05/13] 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 77e45c7..0cc19e7 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -498,6 +498,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;
@@ -509,9 +510,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)
@@ -590,15 +607,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 06/13] 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 0cc19e7..b7c6de1 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1119,6 +1119,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 07/13] cfg80211: only export disable flag on channel disablement

[Luis R. Rodriguez]

When a channel is disabled there is no need to stuff it
with more flags.

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

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index b7c6de1..499bbbe 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -867,7 +867,7 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 			   unsigned int chan_idx)
 {
 	int r;
-	u32 flags;
+	u32 flags, rule_flags;
 	u32 max_bandwidth = 0;
 	const struct ieee80211_reg_rule *reg_rule = NULL;
 	const struct ieee80211_power_rule *power_rule = NULL;
@@ -913,15 +913,19 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
 					"Country IE\n",
 					chan->center_freq, wiphy_name(wiphy));
 #endif
-			flags |= IEEE80211_CHAN_DISABLED;
-			chan->flags = flags;
+			chan->flags = IEEE80211_CHAN_DISABLED;
 		}
 		return;
 	}
 
 	power_rule = &reg_rule->power_rule;
 
-	chan->flags = flags | map_regdom_flags(reg_rule->flags);
+	rule_flags = map_regdom_flags(reg_rule->flags);
+	if (flags & IEEE80211_CHAN_DISABLED)
+		chan->flags = IEEE80211_CHAN_DISABLED;
+	else
+		chan->flags = flags | rule_flags;
+
 	chan->max_antenna_gain = min(chan->orig_mag,
 		(int) MBI_TO_DBI(power_rule->max_antenna_gain));
 	chan->max_bandwidth = KHZ_TO_MHZ(max_bandwidth);
-- 
1.6.1.rc3.51.g5832d

[PATCH 09/13] cfg80211: rename fw_handles_regulatory to custom_regulatory

[Luis R. Rodriguez]

Drivers without firmware can also have custom regulatory maps
which do not map to a specific ISO / IEC alpha2 country code.

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

diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index d2ef3e1..1d568ac 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -811,7 +811,7 @@ int iwl_setup_mac(struct iwl_priv *priv)
 		BIT(NL80211_IFTYPE_STATION) |
 		BIT(NL80211_IFTYPE_ADHOC);
 
-	hw->wiphy->fw_handles_regulatory = true;
+	hw->wiphy->custom_regulatory = true;
 
 	/* Default value; 4 EDCA QOS priorities */
 	hw->queues = 4;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 15425a0..bbd44d5 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -7388,7 +7388,7 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
 		BIT(NL80211_IFTYPE_STATION) |
 		BIT(NL80211_IFTYPE_ADHOC);
 
-	hw->wiphy->fw_handles_regulatory = true;
+	hw->wiphy->custom_regulatory = true;
 
 	/* 4 EDCA QOS priorities */
 	hw->queues = 4;
diff --git a/include/net/wireless.h b/include/net/wireless.h
index 232047b..21e45bf 100644
--- a/include/net/wireless.h
+++ b/include/net/wireless.h
@@ -184,8 +184,8 @@ struct ieee80211_supported_band {
  * @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
+ * @custom_regulatory: tells us the driver for this device
+ * 	has its own custom regulatory domain and cannot identify the
  * 	ISO / IEC 3166 alpha2 it belongs to. When this is enabled
  * 	we will disregard the first regulatory hint (when the
  * 	initiator is %REGDOM_SET_BY_CORE).
@@ -204,7 +204,7 @@ struct wiphy {
 	/* Supported interface modes, OR together BIT(NL80211_IFTYPE_...) */
 	u16 interface_modes;
 
-	bool fw_handles_regulatory;
+	bool custom_regulatory;
 	bool ignore_country_ies;
 
 	/* If multiple wiphys are registered and you're handed e.g.
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index f0ad937..8bf999d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1009,7 +1009,7 @@ static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
 	if (!last_request)
 		return true;
 	if (setby == REGDOM_SET_BY_CORE &&
-		  wiphy->fw_handles_regulatory)
+		  wiphy->custom_regulatory)
 		return true;
 	return false;
 }
-- 
1.6.1.rc3.51.g5832d

[PATCH 10/13] cfg80211: remove check for last_request on ignore_reg_update()

[Luis R. Rodriguez]

There is no need to check for last_request as the callers of
update_all_wiphy_regulatory() ensure its present.

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

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 8bf999d..6c45832 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1006,8 +1006,6 @@ static void handle_band_custom(struct wiphy *wiphy, enum ieee80211_band band,
 
 static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
 {
-	if (!last_request)
-		return true;
 	if (setby == REGDOM_SET_BY_CORE &&
 		  wiphy->custom_regulatory)
 		return true;
-- 
1.6.1.rc3.51.g5832d

[PATCH 11/13] cfg80211: move check for ignore_reg_update() on wiphy_update_regulatory()

[Luis R. Rodriguez]

This ensures that the initial REGDOM_SET_BY_CORE upon wiphy registration
respects the wiphy->custom_regulatory setting. Without this and if OLD_REG
is disabled (which will be default soon as we remove it) the
wiphy->custom_regulatory is simply ignored.

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

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 6c45832..271b54a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1017,13 +1017,15 @@ static void update_all_wiphy_regulatory(enum reg_set_by setby)
 	struct cfg80211_registered_device *drv;
 
 	list_for_each_entry(drv, &cfg80211_drv_list, list)
-		if (!ignore_reg_update(&drv->wiphy, setby))
-			wiphy_update_regulatory(&drv->wiphy, setby);
+		wiphy_update_regulatory(&drv->wiphy, setby);
 }
 
 void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
 {
 	enum ieee80211_band band;
+
+	if (ignore_reg_update(wiphy, setby))
+		return;
 	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
 		if (wiphy->bands[band])
 			handle_band(wiphy, band);
-- 
1.6.1.rc3.51.g5832d

[PATCH 12/13] mac80211: allow mac80211 drivers to get to struct ieee80211_hw 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 wiphy_to_ieee80211_hw() to get first
to its ieee80211_hw and then access the private structure via hw->priv. The
wiphy_priv() is already being used internally by mac80211 and drivers
should not use this. This can be helpful in a drivers reg_notifier().

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

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 9a5869e..b29c41b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -965,6 +965,19 @@ struct ieee80211_hw {
 };
 
 /**
+ * wiphy_to_ieee80211_hw - return a mac80211 driver hw struct from a wiphy
+ *
+ * @wiphy: the &struct wiphy which we want to query
+ *
+ * mac80211 drivers can use this to get to their respective
+ * &struct ieee80211_hw. Drivers wishing to get to their own private
+ * structure can then access it via hw->priv. Note that mac802111 drivers should
+ * not use wiphy_priv() to try to get their private driver structure as this
+ * is already used internally by mac80211.
+ */
+struct ieee80211_hw *wiphy_to_ieee80211_hw(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..9016c8d 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 };
 
+struct ieee80211_hw *wiphy_to_ieee80211_hw(struct wiphy *wiphy)
+{
+	struct ieee80211_local *local;
+	BUG_ON(!wiphy);
+
+	local = wiphy_priv(wiphy);
+	return &local->hw;
+}
+EXPORT_SYMBOL(wiphy_to_ieee80211_hw);
 
 u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
 			enum nl80211_iftype type)
-- 
1.6.1.rc3.51.g5832d

[PATCH 13/13] 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/nl80211.c                     |    5 -
 net/wireless/reg.c                         |  161 +++-------------------------
 4 files changed, 26 insertions(+), 204 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/nl80211.c b/net/wireless/nl80211.c
index 123d3b1..2e7f9eb 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1896,11 +1896,6 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
 
 	data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
 
-#ifdef CONFIG_WIRELESS_OLD_REGULATORY
-	/* We ignore world regdom requests with the old regdom setup */
-	if (is_world_regdom(data))
-		return -EINVAL;
-#endif
 	mutex_lock(&cfg80211_drv_mutex);
 	r = __regulatory_hint(NULL, REGDOM_SET_BY_USER, data, 0, ENVIRON_ANY);
 	mutex_unlock(&cfg80211_drv_mutex);
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 271b54a..d91a046 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -110,103 +110,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 */
@@ -216,8 +119,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);
@@ -1203,16 +1104,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);
 }
 
@@ -1467,16 +1358,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;
 
@@ -1548,24 +1434,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;
@@ -1634,19 +1514,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);
@@ -1654,8 +1521,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 01/13] cfg80211: print correct intersected regulatory domain

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> 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>

Acked-by: Johannes Berg <johannes@sipsolutions.net>

> ---
>  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");

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

Re: [PATCH 02/13] cfg80211: add option for wiphys to disregard country IEs

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> 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.

Can you say why? This doesn't seem useful to me.

> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  include/net/wireless.h |    4 ++++
>  net/wireless/reg.c     |   19 +++++++++++++++++--
>  2 files changed, 21 insertions(+), 2 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 ec8b3d9..01da946 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -782,6 +782,20 @@ static u32 map_regdom_flags(u32 rd_flags)
>  	return channel_flags;
>  }
>  
> +/* 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 (!wiphy->regd)
> +		return false;
> +	if (wiphy->ignore_country_ies)
> +		return true;
> +	if (last_request->initiator != REGDOM_SET_BY_COUNTRY_IE)
> +		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
> @@ -883,7 +897,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 "
> @@ -895,7 +909,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",

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

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:

>  /**
>   * enum reg_set_by - Indicates who is trying to set the regulatory domain
> + * @REGDOM_SET_BY_PROBE: regulatory domain applied came prior to wiphy
> + * 	registration by the driver itself using some custom regulatory
> + * 	information.

This is unnecessary, I think.

> +/**
> + * 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,
> +			 const struct ieee80211_reg_rule **reg_rule)
> +{
> +	return freq_reg_info_regd(wiphy, center_freq,
> +		bandwidth, reg_rule, NULL);
> +}

Are you not using this or am I just not seeing the user?

> +static void handle_channel_custom(struct wiphy *wiphy,
> +				  enum ieee80211_band band,
> +				  unsigned int chan_idx,
> +				  const struct ieee80211_regdomain *regd)
> +{
> +	int r;
> +	u32 max_bandwidth = 0;
> +	const struct ieee80211_reg_rule *reg_rule = NULL;
> +	const struct ieee80211_power_rule *power_rule = NULL;
> +	struct ieee80211_supported_band *sband;
> +	struct ieee80211_channel *chan;
> +
> +	sband = wiphy->bands[band];
> +	BUG_ON(chan_idx >= sband->n_channels);
> +	chan = &sband->channels[chan_idx];
> +
> +	r = freq_reg_info_regd(wiphy, MHZ_TO_KHZ(chan->center_freq),
> +		&max_bandwidth, &reg_rule, regd);
> +
> +	if (r) {
> +		chan->flags = IEEE80211_CHAN_DISABLED;
> +		return;
> +	}
> +
> +	power_rule = &reg_rule->power_rule;
> +
> +	chan->flags |= map_regdom_flags(reg_rule->flags);
> +	chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain);
> +	chan->max_bandwidth = KHZ_TO_MHZ(max_bandwidth);
> +	chan->max_power = (int) MBM_TO_DBM(power_rule->max_eirp);
> +}
> +
> +
>  static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
>  {
>  	unsigned int i;
> @@ -947,6 +989,19 @@ static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
>  		handle_channel(wiphy, band, i);
>  }
>  
> +static void handle_band_custom(struct wiphy *wiphy, enum ieee80211_band band,
> +			       const struct ieee80211_regdomain *regd)
> +{
> +	unsigned int i;
> +	struct ieee80211_supported_band *sband;
> +
> +	BUG_ON(!wiphy->bands[band]);
> +	sband = wiphy->bands[band];
> +
> +	for (i = 0; i < sband->n_channels; i++)
> +		handle_channel_custom(wiphy, band, i, regd);
> +}
> +
>  static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
>  {
>  	if (!last_request)
> @@ -977,6 +1032,20 @@ void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
>  		wiphy->reg_notifier(wiphy, setby);
>  }
>  
> +/* Used by drivers prior to wiphy registration */
> +void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
> +				   const struct ieee80211_regdomain *regd)
> +{
> +	enum ieee80211_band band;
> +	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
> +		if (wiphy->bands[band])
> +			handle_band_custom(wiphy, band, regd);
> +	}
> +	if (wiphy->reg_notifier)
> +		wiphy->reg_notifier(wiphy, REGDOM_SET_BY_PROBE);
> +}
> +EXPORT_SYMBOL(wiphy_apply_custom_regulatory);

Can you group all these functions together, rather than interspersing
them with the others? Also, I don't think calling the notifier is
appropriate since the driver just called this function.

johannes

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

Re: [PATCH 05/13] cfg80211: Fix sanity check on 5 GHz when processing country IE

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> 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.

I'll just believe you here :)

> 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 77e45c7..0cc19e7 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -498,6 +498,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;
> @@ -509,9 +510,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)
> @@ -590,15 +607,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));
>  

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

Re: [PATCH 06/13] cfg80211: process user requests only after previous user/driver/core requests

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> This prevents user regulatory changes to be considered prior to previous
> pending user, core or driver requests which have not be applied.

This seems appropriate, given that we don't actually keep track of
requests that were successful or not.

> 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 0cc19e7..b7c6de1 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1119,6 +1119,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;
>  	}
>  

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

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> When a channel is disabled there is no need to stuff it
> with more flags.

> -	u32 flags;
> +	u32 flags, rule_flags;
>  	u32 max_bandwidth = 0;
>  	const struct ieee80211_reg_rule *reg_rule = NULL;
>  	const struct ieee80211_power_rule *power_rule = NULL;
> @@ -913,15 +913,19 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
>  					"Country IE\n",
>  					chan->center_freq, wiphy_name(wiphy));
>  #endif
> -			flags |= IEEE80211_CHAN_DISABLED;
> -			chan->flags = flags;
> +			chan->flags = IEEE80211_CHAN_DISABLED;
>  		}
>  		return;
>  	}
>  
>  	power_rule = &reg_rule->power_rule;
>  
> -	chan->flags = flags | map_regdom_flags(reg_rule->flags);
> +	rule_flags = map_regdom_flags(reg_rule->flags);
> +	if (flags & IEEE80211_CHAN_DISABLED)
> +		chan->flags = IEEE80211_CHAN_DISABLED;
> +	else
> +		chan->flags = flags | rule_flags;

but why bother with more complicated code when adding a few more flags
doesn't hurt?

johannes

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

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> When a driver issues a regulatory_hint() lets save the received
> values as original channel settings. This allows users to change
> regulatory domains multiple times while always respecting the driver's
> own regulatory setings.

This definitely isn't the right way to do things here. This means that
my card that's programmed to US can never do channel 13 here, something
which on b43 we definitely want to allow.

> 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 499bbbe..f0ad937 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -914,6 +914,9 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
>  					chan->center_freq, wiphy_name(wiphy));
>  #endif
>  			chan->flags = IEEE80211_CHAN_DISABLED;
> +			if (last_request->initiator == REGDOM_SET_BY_DRIVER &&
> +			    last_request->wiphy && last_request->wiphy == wiphy)
> +				chan->orig_flags = chan->flags;
>  		}
>  		return;
>  	}
> @@ -934,6 +937,13 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
>  			(int) MBM_TO_DBM(power_rule->max_eirp));
>  	else
>  		chan->max_power = (int) MBM_TO_DBM(power_rule->max_eirp);
> +
> +	if (last_request->initiator == REGDOM_SET_BY_DRIVER &&
> +	    last_request->wiphy && last_request->wiphy == wiphy) {
> +		chan->orig_flags = chan->flags;
> +		chan->orig_mag = chan->max_antenna_gain;
> +		chan->orig_mpwr = chan->max_power;
> +	}
>  }
>  
>  static void handle_channel_custom(struct wiphy *wiphy,

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

Re: [PATCH 09/13] cfg80211: rename fw_handles_regulatory to custom_regulatory

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> Drivers without firmware can also have custom regulatory maps
> which do not map to a specific ISO / IEC alpha2 country code.

Seems fine.

> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  drivers/net/wireless/iwlwifi/iwl-core.c     |    2 +-
>  drivers/net/wireless/iwlwifi/iwl3945-base.c |    2 +-
>  include/net/wireless.h                      |    6 +++---
>  net/wireless/reg.c                          |    2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
> index d2ef3e1..1d568ac 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-core.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-core.c
> @@ -811,7 +811,7 @@ int iwl_setup_mac(struct iwl_priv *priv)
>  		BIT(NL80211_IFTYPE_STATION) |
>  		BIT(NL80211_IFTYPE_ADHOC);
>  
> -	hw->wiphy->fw_handles_regulatory = true;
> +	hw->wiphy->custom_regulatory = true;
>  
>  	/* Default value; 4 EDCA QOS priorities */
>  	hw->queues = 4;
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 15425a0..bbd44d5 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -7388,7 +7388,7 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
>  		BIT(NL80211_IFTYPE_STATION) |
>  		BIT(NL80211_IFTYPE_ADHOC);
>  
> -	hw->wiphy->fw_handles_regulatory = true;
> +	hw->wiphy->custom_regulatory = true;
>  
>  	/* 4 EDCA QOS priorities */
>  	hw->queues = 4;
> diff --git a/include/net/wireless.h b/include/net/wireless.h
> index 232047b..21e45bf 100644
> --- a/include/net/wireless.h
> +++ b/include/net/wireless.h
> @@ -184,8 +184,8 @@ struct ieee80211_supported_band {
>   * @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
> + * @custom_regulatory: tells us the driver for this device
> + * 	has its own custom regulatory domain and cannot identify the
>   * 	ISO / IEC 3166 alpha2 it belongs to. When this is enabled
>   * 	we will disregard the first regulatory hint (when the
>   * 	initiator is %REGDOM_SET_BY_CORE).
> @@ -204,7 +204,7 @@ struct wiphy {
>  	/* Supported interface modes, OR together BIT(NL80211_IFTYPE_...) */
>  	u16 interface_modes;
>  
> -	bool fw_handles_regulatory;
> +	bool custom_regulatory;
>  	bool ignore_country_ies;
>  
>  	/* If multiple wiphys are registered and you're handed e.g.
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index f0ad937..8bf999d 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1009,7 +1009,7 @@ static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
>  	if (!last_request)
>  		return true;
>  	if (setby == REGDOM_SET_BY_CORE &&
> -		  wiphy->fw_handles_regulatory)
> +		  wiphy->custom_regulatory)
>  		return true;
>  	return false;
>  }

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

Re: [PATCH 10/13] cfg80211: remove check for last_request on ignore_reg_update()

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> There is no need to check for last_request as the callers of
> update_all_wiphy_regulatory() ensure its present.

Are you sure? I had all this blow up all around me.

> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  net/wireless/reg.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 8bf999d..6c45832 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1006,8 +1006,6 @@ static void handle_band_custom(struct wiphy *wiphy, enum ieee80211_band band,
>  
>  static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
>  {
> -	if (!last_request)
> -		return true;
>  	if (setby == REGDOM_SET_BY_CORE &&
>  		  wiphy->custom_regulatory)
>  		return true;

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

Re: [PATCH 11/13] cfg80211: move check for ignore_reg_update() on wiphy_update_regulatory()

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> This ensures that the initial REGDOM_SET_BY_CORE upon wiphy registration
> respects the wiphy->custom_regulatory setting. Without this and if OLD_REG
> is disabled (which will be default soon as we remove it) the
> wiphy->custom_regulatory is simply ignored.
> 
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

Acked-by: Johannes Berg <johannes@sipsolutions.net>

> ---
>  net/wireless/reg.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 6c45832..271b54a 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1017,13 +1017,15 @@ static void update_all_wiphy_regulatory(enum reg_set_by setby)
>  	struct cfg80211_registered_device *drv;
>  
>  	list_for_each_entry(drv, &cfg80211_drv_list, list)
> -		if (!ignore_reg_update(&drv->wiphy, setby))
> -			wiphy_update_regulatory(&drv->wiphy, setby);
> +		wiphy_update_regulatory(&drv->wiphy, setby);
>  }
>  
>  void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
>  {
>  	enum ieee80211_band band;
> +
> +	if (ignore_reg_update(wiphy, setby))
> +		return;
>  	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
>  		if (wiphy->bands[band])
>  			handle_band(wiphy, band);

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

Re: [PATCH 12/13] mac80211: allow mac80211 drivers to get to struct ieee80211_hw from wiphy

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -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 wiphy_to_ieee80211_hw() to get first
> to its ieee80211_hw and then access the private structure via hw->priv. The
> wiphy_priv() is already being used internally by mac80211 and drivers
> should not use this. This can be helpful in a drivers reg_notifier().
> 
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

Acked-by: Johannes Berg <johannes@sipsolutions.net>

> ---
>  include/net/mac80211.h |   13 +++++++++++++
>  net/mac80211/util.c    |    9 +++++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 9a5869e..b29c41b 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -965,6 +965,19 @@ struct ieee80211_hw {
>  };
>  
>  /**
> + * wiphy_to_ieee80211_hw - return a mac80211 driver hw struct from a wiphy
> + *
> + * @wiphy: the &struct wiphy which we want to query
> + *
> + * mac80211 drivers can use this to get to their respective
> + * &struct ieee80211_hw. Drivers wishing to get to their own private
> + * structure can then access it via hw->priv. Note that mac802111 drivers should
> + * not use wiphy_priv() to try to get their private driver structure as this
> + * is already used internally by mac80211.
> + */
> +struct ieee80211_hw *wiphy_to_ieee80211_hw(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..9016c8d 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 };
>  
> +struct ieee80211_hw *wiphy_to_ieee80211_hw(struct wiphy *wiphy)
> +{
> +	struct ieee80211_local *local;
> +	BUG_ON(!wiphy);
> +
> +	local = wiphy_priv(wiphy);
> +	return &local->hw;
> +}
> +EXPORT_SYMBOL(wiphy_to_ieee80211_hw);
>  
>  u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
>  			enum nl80211_iftype type)

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

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

[Johannes Berg]

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

On Thu, 2009-01-15 at 16:12 -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.

Alright, fine, I still run this because my distro hasn't picked up crda
yet, but I guess that just means I need to get my distro to do that.

> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  Documentation/feature-removal-schedule.txt |   18 ---
>  net/wireless/Kconfig                       |   46 +++------
>  net/wireless/nl80211.c                     |    5 -
>  net/wireless/reg.c                         |  161 +++-------------------------
>  4 files changed, 26 insertions(+), 204 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/nl80211.c b/net/wireless/nl80211.c
> index 123d3b1..2e7f9eb 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -1896,11 +1896,6 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
>  
>  	data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
>  
> -#ifdef CONFIG_WIRELESS_OLD_REGULATORY
> -	/* We ignore world regdom requests with the old regdom setup */
> -	if (is_world_regdom(data))
> -		return -EINVAL;
> -#endif
>  	mutex_lock(&cfg80211_drv_mutex);
>  	r = __regulatory_hint(NULL, REGDOM_SET_BY_USER, data, 0, ENVIRON_ANY);
>  	mutex_unlock(&cfg80211_drv_mutex);
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 271b54a..d91a046 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -110,103 +110,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 */
> @@ -216,8 +119,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);
> @@ -1203,16 +1104,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);
>  }
>  
> @@ -1467,16 +1358,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;
>  
> @@ -1548,24 +1434,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;
> @@ -1634,19 +1514,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);
> @@ -1654,8 +1521,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;
>  }
>  

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

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

[John W. Linville]

On Fri, Jan 16, 2009 at 10:28:11AM +0100, Johannes Berg wrote:
> On Thu, 2009-01-15 at 16:12 -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.
> 
> Alright, fine, I still run this because my distro hasn't picked up crda
> yet, but I guess that just means I need to get my distro to do that.

Distros should pick-up crda, true.  Still, I support Johannes' original
comments that keeping this is not a huge maintenance burden and that
we need not be too hasty to get rid of this.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [PATCH 10/13] cfg80211: remove check for last_request on ignore_reg_update()

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 01:26:30AM -0800, Johannes Berg wrote:
> On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > There is no need to check for last_request as the callers of
> > update_all_wiphy_regulatory() ensure its present.
> 
> Are you sure? I had all this blow up all around me.

Interesting -- well that's the thing, where and why would it have blown up?
I did test it and didn't run into it.

  Luis

> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> >  net/wireless/reg.c |    2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> > index 8bf999d..6c45832 100644
> > --- a/net/wireless/reg.c
> > +++ b/net/wireless/reg.c
> > @@ -1006,8 +1006,6 @@ static void handle_band_custom(struct wiphy *wiphy, enum ieee80211_band band,
> >  
> >  static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
> >  {
> > -	if (!last_request)
> > -		return true;
> >  	if (setby == REGDOM_SET_BY_CORE &&
> >  		  wiphy->custom_regulatory)
> >  		return true;

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 01:25:21AM -0800, Johannes Berg wrote:
> On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > When a driver issues a regulatory_hint() lets save the received
> > values as original channel settings. This allows users to change
> > regulatory domains multiple times while always respecting the driver's
> > own regulatory setings.
> 
> This definitely isn't the right way to do things here. This means that
> my card that's programmed to US can never do channel 13 here, something
> which on b43 we definitely want to allow.

Ah -- are you sure you want to allow for that? It seems I was misunderstanding a bit
how things would be done for 11d in ath9k and the fact is that we *don't* allow
for channels beyond what the programmed regulatory domain allows. This is because
calibration stuff has only been tested/ensured/certified/call-it-what you want
for the channels in that regulatory domain SKU. Are you certain that b43 can operate
well on channels not in their regulatory domain SKU? If so then how about a wiphy flag
to let drivers pick this.

  Luis

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 01:23:47AM -0800, Johannes Berg wrote:
> On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > When a channel is disabled there is no need to stuff it
> > with more flags.
> 
> > -	u32 flags;
> > +	u32 flags, rule_flags;
> >  	u32 max_bandwidth = 0;
> >  	const struct ieee80211_reg_rule *reg_rule = NULL;
> >  	const struct ieee80211_power_rule *power_rule = NULL;
> > @@ -913,15 +913,19 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
> >  					"Country IE\n",
> >  					chan->center_freq, wiphy_name(wiphy));
> >  #endif
> > -			flags |= IEEE80211_CHAN_DISABLED;
> > -			chan->flags = flags;
> > +			chan->flags = IEEE80211_CHAN_DISABLED;
> >  		}
> >  		return;
> >  	}
> >  
> >  	power_rule = &reg_rule->power_rule;
> >  
> > -	chan->flags = flags | map_regdom_flags(reg_rule->flags);
> > +	rule_flags = map_regdom_flags(reg_rule->flags);
> > +	if (flags & IEEE80211_CHAN_DISABLED)
> > +		chan->flags = IEEE80211_CHAN_DISABLED;
> > +	else
> > +		chan->flags = flags | rule_flags;
> 
> but why bother with more complicated code when adding a few more flags
> doesn't hurt?

I don't see these few lines as complicated really, but if you don't like them
that's fine. We can also fix this in userspace so that disable|radar|no-ibss
doesn't show up. I frankly think its pointless to keep them though.

  Luis

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 01:20:59AM -0800, Johannes Berg wrote:
> On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> 
> >  /**
> >   * enum reg_set_by - Indicates who is trying to set the regulatory domain
> > + * @REGDOM_SET_BY_PROBE: regulatory domain applied came prior to wiphy
> > + * 	registration by the driver itself using some custom regulatory
> > + * 	information.
> 
> This is unnecessary, I think.

I'll make note of it below.

> > +/**
> > + * 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,
> > +			 const struct ieee80211_reg_rule **reg_rule)
> > +{
> > +	return freq_reg_info_regd(wiphy, center_freq,
> > +		bandwidth, reg_rule, NULL);
> > +}
> 
> Are you not using this or am I just not seeing the user?

Yeah -- good catch, its just cruft left over from my previous work.

> > +static void handle_channel_custom(struct wiphy *wiphy,
> > +				  enum ieee80211_band band,
> > +				  unsigned int chan_idx,
> > +				  const struct ieee80211_regdomain *regd)
> > +{
> > +	int r;
> > +	u32 max_bandwidth = 0;
> > +	const struct ieee80211_reg_rule *reg_rule = NULL;
> > +	const struct ieee80211_power_rule *power_rule = NULL;
> > +	struct ieee80211_supported_band *sband;
> > +	struct ieee80211_channel *chan;
> > +
> > +	sband = wiphy->bands[band];
> > +	BUG_ON(chan_idx >= sband->n_channels);
> > +	chan = &sband->channels[chan_idx];
> > +
> > +	r = freq_reg_info_regd(wiphy, MHZ_TO_KHZ(chan->center_freq),
> > +		&max_bandwidth, &reg_rule, regd);
> > +
> > +	if (r) {
> > +		chan->flags = IEEE80211_CHAN_DISABLED;
> > +		return;
> > +	}
> > +
> > +	power_rule = &reg_rule->power_rule;
> > +
> > +	chan->flags |= map_regdom_flags(reg_rule->flags);
> > +	chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain);
> > +	chan->max_bandwidth = KHZ_TO_MHZ(max_bandwidth);
> > +	chan->max_power = (int) MBM_TO_DBM(power_rule->max_eirp);
> > +}
> > +
> > +
> >  static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
> >  {
> >  	unsigned int i;
> > @@ -947,6 +989,19 @@ static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
> >  		handle_channel(wiphy, band, i);
> >  }
> >  
> > +static void handle_band_custom(struct wiphy *wiphy, enum ieee80211_band band,
> > +			       const struct ieee80211_regdomain *regd)
> > +{
> > +	unsigned int i;
> > +	struct ieee80211_supported_band *sband;
> > +
> > +	BUG_ON(!wiphy->bands[band]);
> > +	sband = wiphy->bands[band];
> > +
> > +	for (i = 0; i < sband->n_channels; i++)
> > +		handle_channel_custom(wiphy, band, i, regd);
> > +}
> > +
> >  static bool ignore_reg_update(struct wiphy *wiphy, enum reg_set_by setby)
> >  {
> >  	if (!last_request)
> > @@ -977,6 +1032,20 @@ void wiphy_update_regulatory(struct wiphy *wiphy, enum reg_set_by setby)
> >  		wiphy->reg_notifier(wiphy, setby);
> >  }
> >  
> > +/* Used by drivers prior to wiphy registration */
> > +void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
> > +				   const struct ieee80211_regdomain *regd)
> > +{
> > +	enum ieee80211_band band;
> > +	for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
> > +		if (wiphy->bands[band])
> > +			handle_band_custom(wiphy, band, regd);
> > +	}
> > +	if (wiphy->reg_notifier)
> > +		wiphy->reg_notifier(wiphy, REGDOM_SET_BY_PROBE);
> > +}
> > +EXPORT_SYMBOL(wiphy_apply_custom_regulatory);
> 
> Can you group all these functions together, rather than interspersing
> them with the others?

Yeah sure.

> Also, I don't think calling the notifier is
> appropriate since the driver just called this function.

Calling the notifier is why we want REGDOM_SET_BY_PROBE. We also technically
do not need to call the notifier unless we want to allow for tricks like the
one I am using in ath9k to condense the regulatory domains to 5 based on frequency
and to let a helper sort out the flags. Without this I believe we'd be forced to
use 12 full blown regds.

  Luis

Re: [PATCH 02/13] cfg80211: add option for wiphys to disregard country IEs

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 01:17:12AM -0800, Johannes Berg wrote:
> On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > 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.
> 
> Can you say why? This doesn't seem useful to me.

Its based on our internal regulatory policy for our hardware. If you have
a alpha2 map you should disregard the country IE. If you have a world regdom
you can follow the IE (but not enable more). Technically I think that without
this things may work now to respect the original driver stuff though with the
new orig_* changes, will need to test.

  Luis

Re: [PATCH 10/13] cfg80211: remove check for last_request on ignore_reg_update()

[Johannes Berg]

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

On Fri, 2009-01-16 at 08:27 -0800, Luis R. Rodriguez wrote:
> On Fri, Jan 16, 2009 at 01:26:30AM -0800, Johannes Berg wrote:
> > On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > > There is no need to check for last_request as the callers of
> > > update_all_wiphy_regulatory() ensure its present.
> > 
> > Are you sure? I had all this blow up all around me.
> 
> Interesting -- well that's the thing, where and why would it have blown up?
> I did test it and didn't run into it.

Only w/o crda and old-regulatory did I see that happen though, not sure.

johannes

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

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Johannes Berg]

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

On Fri, 2009-01-16 at 08:31 -0800, Luis R. Rodriguez wrote:
> On Fri, Jan 16, 2009 at 01:25:21AM -0800, Johannes Berg wrote:
> > On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > > When a driver issues a regulatory_hint() lets save the received
> > > values as original channel settings. This allows users to change
> > > regulatory domains multiple times while always respecting the driver's
> > > own regulatory setings.
> > 
> > This definitely isn't the right way to do things here. This means that
> > my card that's programmed to US can never do channel 13 here, something
> > which on b43 we definitely want to allow.
> 
> Ah -- are you sure you want to allow for that? 

Yes.

> It seems I was misunderstanding a bit
> how things would be done for 11d in ath9k and the fact is that we *don't* allow
> for channels beyond what the programmed regulatory domain allows. This is because
> calibration stuff has only been tested/ensured/certified/call-it-what you want
> for the channels in that regulatory domain SKU. 

Yes, I know why you want this, but I think you should do it slightly
differently.

> Are you certain that b43 can operate
> well on channels not in their regulatory domain SKU? If so then how about a wiphy flag
> to let drivers pick this.

I don't see a need for a flag. We just need to have the driver set
orig_flags rather than cfg80211, no?

johannes

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

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Johannes Berg]

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

On Fri, 2009-01-16 at 08:32 -0800, Luis R. Rodriguez wrote:

> > > -	chan->flags = flags | map_regdom_flags(reg_rule->flags);
> > > +	rule_flags = map_regdom_flags(reg_rule->flags);
> > > +	if (flags & IEEE80211_CHAN_DISABLED)
> > > +		chan->flags = IEEE80211_CHAN_DISABLED;
> > > +	else
> > > +		chan->flags = flags | rule_flags;
> > 
> > but why bother with more complicated code when adding a few more flags
> > doesn't hurt?
> 
> I don't see these few lines as complicated really, but if you don't like them
> that's fine. We can also fix this in userspace so that disable|radar|no-ibss
> doesn't show up. I frankly think its pointless to keep them though.

It's not exactly complicated, but I bet at some point we'll scratch our
heads why we did it ;)

johannes

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

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Johannes Berg]

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

On Fri, 2009-01-16 at 08:36 -0800, Luis R. Rodriguez wrote:

> > Also, I don't think calling the notifier is
> > appropriate since the driver just called this function.
> 
> Calling the notifier is why we want REGDOM_SET_BY_PROBE. We also technically
> do not need to call the notifier unless we want to allow for tricks like the
> one I am using in ath9k to condense the regulatory domains to 5 based on frequency
> and to let a helper sort out the flags. Without this I believe we'd be forced to
> use 12 full blown regds.

I just don't see why the driver couldn't be like this:

static void helper(...) {...}

static void ath9k_reg_notifier(...) {
	helper(...)
}

static void ath9k_something(...) {
	apply_custom_regulatory(..)
	helper(..)
}

so cfg80211 doesn't call back into it but it does it itself. It's
usually deadlock prone if some called code calls back into the caller
code.

johannes

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

Re: [PATCH 02/13] cfg80211: add option for wiphys to disregard country IEs

[Johannes Berg]

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

On Fri, 2009-01-16 at 08:40 -0800, Luis R. Rodriguez wrote:
> On Fri, Jan 16, 2009 at 01:17:12AM -0800, Johannes Berg wrote:
> > On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > > 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.
> > 
> > Can you say why? This doesn't seem useful to me.
> 
> Its based on our internal regulatory policy for our hardware. If you have
> a alpha2 map you should disregard the country IE. If you have a world regdom
> you can follow the IE (but not enable more). Technically I think that without
> this things may work now to respect the original driver stuff though with the
> new orig_* changes, will need to test.

I think it should work w/o this, yeah, and I also think we should follow
the 11d hint if it restricts us further rather than just ignoring it.

johannes

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

Re: [PATCH 10/13] cfg80211: remove check for last_request on ignore_reg_update()

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 12:33:00PM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 08:27 -0800, Luis R. Rodriguez wrote:
> > On Fri, Jan 16, 2009 at 01:26:30AM -0800, Johannes Berg wrote:
> > > On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > > > There is no need to check for last_request as the callers of
> > > > update_all_wiphy_regulatory() ensure its present.
> > > 
> > > Are you sure? I had all this blow up all around me.
> > 
> > Interesting -- well that's the thing, where and why would it have blown up?
> > I did test it and didn't run into it.
> 
> Only w/o crda and old-regulatory did I see that happen though, not sure.

Bleh -- I suppose I'll have to retest this series with OLD_REG enabled after all...

  Luis

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 12:34:22PM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 08:31 -0800, Luis R. Rodriguez wrote:
> > On Fri, Jan 16, 2009 at 01:25:21AM -0800, Johannes Berg wrote:
> > > On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > > > When a driver issues a regulatory_hint() lets save the received
> > > > values as original channel settings. This allows users to change
> > > > regulatory domains multiple times while always respecting the driver's
> > > > own regulatory setings.
> > > 
> > > This definitely isn't the right way to do things here. This means that
> > > my card that's programmed to US can never do channel 13 here, something
> > > which on b43 we definitely want to allow.
> > 
> > Ah -- are you sure you want to allow for that? 
> 
> Yes.
> 
> > It seems I was misunderstanding a bit
> > how things would be done for 11d in ath9k and the fact is that we *don't* allow
> > for channels beyond what the programmed regulatory domain allows. This is because
> > calibration stuff has only been tested/ensured/certified/call-it-what you want
> > for the channels in that regulatory domain SKU. 
> 
> Yes, I know why you want this, but I think you should do it slightly
> differently.
> 
> > Are you certain that b43 can operate
> > well on channels not in their regulatory domain SKU? If so then how about a wiphy flag
> > to let drivers pick this.
> 
> I don't see a need for a flag. 

Well in ath9k we want this, and orig_* stuff is used only for custom
regulatory domains. How would we install information on orig_* from
a regulatory_hint() on drivers if we have drivres which may or may not
want to save that information on orig_* parameters?

> We just need to have the driver set
> orig_flags rather than cfg80211, no?

Oh you mean in the reg_notifier() on REGDOM_SET_BY_DRIVER? Sure, that works
as well, if so desired.

  Luis

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 12:35:01PM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 08:32 -0800, Luis R. Rodriguez wrote:
> 
> > > > -	chan->flags = flags | map_regdom_flags(reg_rule->flags);
> > > > +	rule_flags = map_regdom_flags(reg_rule->flags);
> > > > +	if (flags & IEEE80211_CHAN_DISABLED)
> > > > +		chan->flags = IEEE80211_CHAN_DISABLED;
> > > > +	else
> > > > +		chan->flags = flags | rule_flags;
> > > 
> > > but why bother with more complicated code when adding a few more flags
> > > doesn't hurt?
> > 
> > I don't see these few lines as complicated really, but if you don't like them
> > that's fine. We can also fix this in userspace so that disable|radar|no-ibss
> > doesn't show up. I frankly think its pointless to keep them though.
> 
> It's not exactly complicated, but I bet at some point we'll scratch our
> heads why we did it ;)

I can put a note, if that helps, or are you strongly opposed to this? :)
Just an itch to scratch really, have you seen the output of iwlist on
disabled channels? It can get long on radar/no-ibss channels. We can also
handle this in userspace but seems pointles if the channels is disabled.

  Luis

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 12:37:50PM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 08:36 -0800, Luis R. Rodriguez wrote:
> 
> > > Also, I don't think calling the notifier is
> > > appropriate since the driver just called this function.
> > 
> > Calling the notifier is why we want REGDOM_SET_BY_PROBE. We also technically
> > do not need to call the notifier unless we want to allow for tricks like the
> > one I am using in ath9k to condense the regulatory domains to 5 based on frequency
> > and to let a helper sort out the flags. Without this I believe we'd be forced to
> > use 12 full blown regds.
> 
> I just don't see why the driver couldn't be like this:
> 
> static void helper(...) {...}
> 
> static void ath9k_reg_notifier(...) {
> 	helper(...)
> }
> 
> static void ath9k_something(...) {
> 	apply_custom_regulatory(..)
> 	helper(..)
> }
> 
> so cfg80211 doesn't call back into it but it does it itself. It's
> usually deadlock prone if some called code calls back into the caller
> code.

Sure I'll do it this way then.

  Luis

Re: [PATCH 02/13] cfg80211: add option for wiphys to disregard country IEs

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 12:38:48PM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 08:40 -0800, Luis R. Rodriguez wrote:
> > On Fri, Jan 16, 2009 at 01:17:12AM -0800, Johannes Berg wrote:
> > > On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
> > > > 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.
> > > 
> > > Can you say why? This doesn't seem useful to me.
> > 
> > Its based on our internal regulatory policy for our hardware. If you have
> > a alpha2 map you should disregard the country IE. If you have a world regdom
> > you can follow the IE (but not enable more). Technically I think that without
> > this things may work now to respect the original driver stuff though with the
> > new orig_* changes, will need to test.
> 
> I think it should work w/o this, yeah, and I also think we should follow
> the 11d hint if it restricts us further rather than just ignoring it.

I concur, will test (with OLD_REG and without it, jeesh).

  Luis

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Luis R. Rodriguez]

On Fri, Jan 16, 2009 at 8:36 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, Jan 16, 2009 at 01:20:59AM -0800, Johannes Berg wrote:
>> On Thu, 2009-01-15 at 16:12 -0800, Luis R. Rodriguez wrote:
>>
>> >  /**
>> >   * enum reg_set_by - Indicates who is trying to set the regulatory domain
>> > + * @REGDOM_SET_BY_PROBE: regulatory domain applied came prior to wiphy
>> > + *         registration by the driver itself using some custom regulatory
>> > + *         information.
>>
>> This is unnecessary, I think.
>
> I'll make note of it below.
>
>> > +/**
>> > + * 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,
>> > +                    const struct ieee80211_reg_rule **reg_rule)
>> > +{
>> > +   return freq_reg_info_regd(wiphy, center_freq,
>> > +           bandwidth, reg_rule, NULL);
>> > +}
>>
>> Are you not using this or am I just not seeing the user?
>
> Yeah -- good catch, its just cruft left over from my previous work.

Actually  freq_reg_info_regd() is used by handle_channel_custom(),
hence my comment on re-inventing the wheel. But yeah it used.

  Luis

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Johannes Berg]

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

On Fri, 2009-01-16 at 14:13 -0800, Luis R. Rodriguez wrote:

> >> > +static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
> >> > +                    const struct ieee80211_reg_rule **reg_rule)
> >> > +{
> >> > +   return freq_reg_info_regd(wiphy, center_freq,
> >> > +           bandwidth, reg_rule, NULL);
> >> > +}
> >>
> >> Are you not using this or am I just not seeing the user?
> >
> > Yeah -- good catch, its just cruft left over from my previous work.
> 
> Actually  freq_reg_info_regd() is used by handle_channel_custom(),
> hence my comment on re-inventing the wheel. But yeah it used.

Yeah but not freq_reg_info?

johannes

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

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Luis R. Rodriguez]

On Sat, Jan 17, 2009 at 01:30:49AM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 14:13 -0800, Luis R. Rodriguez wrote:
> 
> > >> > +static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
> > >> > +                    const struct ieee80211_reg_rule **reg_rule)
> > >> > +{
> > >> > +   return freq_reg_info_regd(wiphy, center_freq,
> > >> > +           bandwidth, reg_rule, NULL);
> > >> > +}
> > >>
> > >> Are you not using this or am I just not seeing the user?
> > >
> > > Yeah -- good catch, its just cruft left over from my previous work.
> > 
> > Actually  freq_reg_info_regd() is used by handle_channel_custom(),
> > hence my comment on re-inventing the wheel. But yeah it used.
> 
> Yeah but not freq_reg_info?

That one is used by the reg_notifier() in ath9k to inspect the country IE
regulatory domain processed.

  Luis

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Johannes Berg]

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

On Fri, 2009-01-16 at 13:06 -0800, Luis R. Rodriguez wrote:

> Well in ath9k we want this, and orig_* stuff is used only for custom
> regulatory domains. How would we install information on orig_* from
> a regulatory_hint() on drivers if we have drivres which may or may not
> want to save that information on orig_* parameters?

Not sure.

> > We just need to have the driver set
> > orig_flags rather than cfg80211, no?
> 
> Oh you mean in the reg_notifier() on REGDOM_SET_BY_DRIVER? Sure, that works
> as well, if so desired.

Well, I wasn't intending for anything to _ever_ touch orig_flags at
all... I think you're hampered by not being able to simply request a
regdomain from crda outside the normal "apply regdomain" flow, maybe we
should think about that instead? Then ath9k could just request a
regdomain from crda before it even registers its wiphy?

johannes

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

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Johannes Berg]

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

On Fri, 2009-01-16 at 13:09 -0800, Luis R. Rodriguez wrote:

> I can put a note, if that helps, or are you strongly opposed to this? :)
> Just an itch to scratch really, have you seen the output of iwlist on
> disabled channels? It can get long on radar/no-ibss channels. We can also
> handle this in userspace but seems pointles if the channels is disabled.

Well, come to think of it, at least for programmers it might be
confusing when they know they've put some flag into orig_flags, and then
it disappears? I'm not really _strongly_ opposed to this, but I really
just don't see the point :)

johannes

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

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Johannes Berg]

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

On Sat, 2009-01-17 at 14:06 -0800, Luis R. Rodriguez wrote:

> > > >> > +static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
> > > >> > +                    const struct ieee80211_reg_rule **reg_rule)
> > > >> > +{
> > > >> > +   return freq_reg_info_regd(wiphy, center_freq,
> > > >> > +           bandwidth, reg_rule, NULL);
> > > >> > +}
> > > >>
> > > >> Are you not using this or am I just not seeing the user?
> > > >
> > > > Yeah -- good catch, its just cruft left over from my previous work.
> > > 
> > > Actually  freq_reg_info_regd() is used by handle_channel_custom(),
> > > hence my comment on re-inventing the wheel. But yeah it used.
> > 
> > Yeah but not freq_reg_info?
> 
> That one is used by the reg_notifier() in ath9k to inspect the country IE
> regulatory domain processed.

?? It's static and not exported, so how can ath9k use it?

johannes

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

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Luis R. Rodriguez]

On Sun, Jan 18, 2009 at 12:47:29AM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 13:06 -0800, Luis R. Rodriguez wrote:
> 
> > Well in ath9k we want this, and orig_* stuff is used only for custom
> > regulatory domains. How would we install information on orig_* from
> > a regulatory_hint() on drivers if we have drivres which may or may not
> > want to save that information on orig_* parameters?
> 
> Not sure.

The answer was above, but lets see.

> > > We just need to have the driver set
> > > orig_flags rather than cfg80211, no?
> > 
> > Oh you mean in the reg_notifier() on REGDOM_SET_BY_DRIVER? Sure, that works
> > as well, if so desired.
> 
> Well, I wasn't intending for anything to _ever_ touch orig_flags at
> all... 

Just so you know the approach I started taking for v3 of this series
was to apply save the orig_* parameters if REGDOM_SET_BY_DRIVER and
the request->wiphy == wiphy. This works OK except if you have "US"
as your regulatory domain and you have OLD_REG set cfg80211 will have
already have called for a new regulatory domain update for "US" so
this is -EALREADY. Some changes are then required to inform drivers
through the reg_notifier() of this. This is where I was at now.

> I think you're hampered by not being able to simply request a
> regdomain from crda outside the normal "apply regdomain" flow, 

Well I have a few approaches already which have worked but I like to 
think we're looking for the most simple solution so its easier to
support this for other drivers as well.

> maybe we
> should think about that instead? Then ath9k could just request a
> regdomain from crda before it even registers its wiphy?

Are you suggesting we consider new API for drivers which want the
behaviour we want? That works for me too, but then again I'd be applying
the save orig_* stuff perhaps at the end of this new, say,
regulatory_hint_strict().

  Luis

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Luis R. Rodriguez]

On Sun, Jan 18, 2009 at 12:48:36AM -0800, Johannes Berg wrote:
> On Fri, 2009-01-16 at 13:09 -0800, Luis R. Rodriguez wrote:
> 
> > I can put a note, if that helps, or are you strongly opposed to this? :)
> > Just an itch to scratch really, have you seen the output of iwlist on
> > disabled channels? It can get long on radar/no-ibss channels. We can also
> > handle this in userspace but seems pointles if the channels is disabled.
> 
> Well, come to think of it, at least for programmers it might be
> confusing when they know they've put some flag into orig_flags, and then
> it disappears? I'm not really _strongly_ opposed to this, but I really
> just don't see the point :)

Have you bothered calling iw list with a long list of crap on the channels?

  Luis

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Luis R. Rodriguez]

On Sun, Jan 18, 2009 at 12:49:17AM -0800, Johannes Berg wrote:
> On Sat, 2009-01-17 at 14:06 -0800, Luis R. Rodriguez wrote:
> 
> > > > >> > +static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
> > > > >> > +                    const struct ieee80211_reg_rule **reg_rule)
> > > > >> > +{
> > > > >> > +   return freq_reg_info_regd(wiphy, center_freq,
> > > > >> > +           bandwidth, reg_rule, NULL);
> > > > >> > +}
> > > > >>
> > > > >> Are you not using this or am I just not seeing the user?
> > > > >
> > > > > Yeah -- good catch, its just cruft left over from my previous work.
> > > > 
> > > > Actually  freq_reg_info_regd() is used by handle_channel_custom(),
> > > > hence my comment on re-inventing the wheel. But yeah it used.
> > > 
> > > Yeah but not freq_reg_info?
> > 
> > That one is used by the reg_notifier() in ath9k to inspect the country IE
> > regulatory domain processed.
> 
> ?? It's static and not exported, so how can ath9k use it?

Patch 04 in this series fixes that.

  Luis

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Johannes Berg]

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

On Sun, 2009-01-18 at 07:28 -0800, Luis R. Rodriguez wrote:

> Just so you know the approach I started taking for v3 of this series
> was to apply save the orig_* parameters if REGDOM_SET_BY_DRIVER and
> the request->wiphy == wiphy. This works OK except if you have "US"
> as your regulatory domain and you have OLD_REG set cfg80211 will have
> already have called for a new regulatory domain update for "US" so
> this is -EALREADY. Some changes are then required to inform drivers
> through the reg_notifier() of this. This is where I was at now.

Yeah, I know.

> > I think you're hampered by not being able to simply request a
> > regdomain from crda outside the normal "apply regdomain" flow, 
> 
> Well I have a few approaches already which have worked but I like to 
> think we're looking for the most simple solution so its easier to
> support this for other drivers as well.

Right.

> > maybe we
> > should think about that instead? Then ath9k could just request a
> > regdomain from crda before it even registers its wiphy?
> 
> Are you suggesting we consider new API for drivers which want the
> behaviour we want? That works for me too, but then again I'd be applying
> the save orig_* stuff perhaps at the end of this new, say,
> regulatory_hint_strict().

Well, I was more thinking to have a 
struct regdomain *cfg80211_ask_crda(const char *alpha2);

but I realise that is very hard to implement with the call to userspace
etc. So yeah, doing something like the _strict you propose seems more
appropriate. Maybe call it something else, not _hint,and have it call
out to userspace regardless (i.e. don't ever ignore that hint, as we
might ignore other hints), say regulatory_apply(wiphy, alpha2)? Not
sure, apply seems not quite right either.

johannes

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

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Johannes Berg]

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

On Sun, 2009-01-18 at 07:30 -0800, Luis R. Rodriguez wrote:
> On Sun, Jan 18, 2009 at 12:48:36AM -0800, Johannes Berg wrote:
> > On Fri, 2009-01-16 at 13:09 -0800, Luis R. Rodriguez wrote:
> > 
> > > I can put a note, if that helps, or are you strongly opposed to this? :)
> > > Just an itch to scratch really, have you seen the output of iwlist on
> > > disabled channels? It can get long on radar/no-ibss channels. We can also
> > > handle this in userspace but seems pointles if the channels is disabled.
> > 
> > Well, come to think of it, at least for programmers it might be
> > confusing when they know they've put some flag into orig_flags, and then
> > it disappears? I'm not really _strongly_ opposed to this, but I really
> > just don't see the point :)
> 
> Have you bothered calling iw list with a long list of crap on the channels?

Heh, no, but I rarely call iw at all. I just added a patch to iw to
suppress it instead, I think that's more appropriate.

johannes

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

Re: [PATCH 03/13] cfg80211: add wiphy_apply_custom_regulatory()

[Johannes Berg]

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

On Sun, 2009-01-18 at 07:31 -0800, Luis R. Rodriguez wrote:
> On Sun, Jan 18, 2009 at 12:49:17AM -0800, Johannes Berg wrote:
> > On Sat, 2009-01-17 at 14:06 -0800, Luis R. Rodriguez wrote:
> > 
> > > > > >> > +static int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
> > > > > >> > +                    const struct ieee80211_reg_rule **reg_rule)
> > > > > >> > +{
> > > > > >> > +   return freq_reg_info_regd(wiphy, center_freq,
> > > > > >> > +           bandwidth, reg_rule, NULL);
> > > > > >> > +}
> > > > > >>
> > > > > >> Are you not using this or am I just not seeing the user?
> > > > > >
> > > > > > Yeah -- good catch, its just cruft left over from my previous work.
> > > > > 
> > > > > Actually  freq_reg_info_regd() is used by handle_channel_custom(),
> > > > > hence my comment on re-inventing the wheel. But yeah it used.
> > > > 
> > > > Yeah but not freq_reg_info?
> > > 
> > > That one is used by the reg_notifier() in ath9k to inspect the country IE
> > > regulatory domain processed.
> > 
> > ?? It's static and not exported, so how can ath9k use it?
> 
> Patch 04 in this series fixes that.

Oh, heh, ok.

johannes

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

Re: [PATCH 08/13] cfg80211: save original values on regulatory hints

[Luis R. Rodriguez]

On Sun, Jan 18, 2009 at 09:12:05AM -0800, Johannes Berg wrote:
> On Sun, 2009-01-18 at 07:28 -0800, Luis R. Rodriguez wrote:
> 
> > Are you suggesting we consider new API for drivers which want the
> > behaviour we want? That works for me too, but then again I'd be applying
> > the save orig_* stuff perhaps at the end of this new, say,
> > regulatory_hint_strict().
> 
> Well, I was more thinking to have a 
> struct regdomain *cfg80211_ask_crda(const char *alpha2);
> 
> but I realise that is very hard to implement with the call to userspace
> etc. So yeah, doing something like the _strict you propose seems more
> appropriate. Maybe call it something else, not _hint,and have it call
> out to userspace regardless (i.e. don't ever ignore that hint, as we
> might ignore other hints), say regulatory_apply(wiphy, alpha2)? Not
> sure, apply seems not quite right either.

I'd definitely would prefer if cfg80211 handled this instead of the drivers
through the reg_notifier(), will go back and try to do that and see if I
can come up with a decent name to indicate what we are doing.

  Luis

Re: [PATCH 07/13] cfg80211: only export disable flag on channel disablement

[Luis R. Rodriguez]

On Sun, Jan 18, 2009 at 09:13:51AM -0800, Johannes Berg wrote:
> On Sun, 2009-01-18 at 07:30 -0800, Luis R. Rodriguez wrote:
> > On Sun, Jan 18, 2009 at 12:48:36AM -0800, Johannes Berg wrote:
> > > On Fri, 2009-01-16 at 13:09 -0800, Luis R. Rodriguez wrote:
> > > 
> > > > I can put a note, if that helps, or are you strongly opposed to this? :)
> > > > Just an itch to scratch really, have you seen the output of iwlist on
> > > > disabled channels? It can get long on radar/no-ibss channels. We can also
> > > > handle this in userspace but seems pointles if the channels is disabled.
> > > 
> > > Well, come to think of it, at least for programmers it might be
> > > confusing when they know they've put some flag into orig_flags, and then
> > > it disappears? I'm not really _strongly_ opposed to this, but I really
> > > just don't see the point :)
> > 
> > Have you bothered calling iw list with a long list of crap on the channels?
> 
> Heh, no, but I rarely call iw at all. I just added a patch to iw to
> suppress it instead, I think that's more appropriate.

:) alright, fine by me.

  Luis