aboutsummaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorLuis R. Rodriguez <lrodriguez@atheros.com>2009-05-02 00:37:17 -0400
committerJohn W. Linville <linville@tuxdriver.com>2009-05-20 14:46:22 -0400
commit038659e7c6b385065cb223872771ac437ef70b62 (patch)
treedf9e86adcc611d10ed5f98672421bffe1f43989f /include
parent97bc54152e3a91dd2dc297e8a084c05e93527e60 (diff)
downloadmrst-s0i3-test-038659e7c6b385065cb223872771ac437ef70b62.tar.gz
mrst-s0i3-test-038659e7c6b385065cb223872771ac437ef70b62.tar.xz
mrst-s0i3-test-038659e7c6b385065cb223872771ac437ef70b62.zip
cfg80211: Process regulatory max bandwidth checks for HT40
We are not correctly listening to the regulatory max bandwidth settings. To actually make use of it we need to redesign things a bit. This patch does the work for that. We do this to so we can obey to regulatory rules accordingly for use of HT40. We end up dealing with HT40 by having two passes for each channel. The first check will see if a 20 MHz channel fits into the channel's center freq on a given frequency range. We check for a 20 MHz banwidth channel as that is the maximum an individual channel will use, at least for now. The first pass will go ahead and check if the regulatory rule for that given center of frequency allows 40 MHz bandwidths and we use this to determine whether or not the channel supports HT40 or not. So to support HT40 you'll need at a regulatory rule that allows you to use 40 MHz channels but you're channel must also be enabled and support 20 MHz by itself. The second pass is done after we do the regulatory checks over an device's supported channel list. On each channel we'll check if the control channel and the extension both: o exist o are enabled o regulatory allows 40 MHz bandwidth on its frequency range This work allows allows us to idependently check for HT40- and HT40+. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'include')
-rw-r--r--include/net/cfg80211.h14
1 files changed, 10 insertions, 4 deletions
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9e17a83d343..282d58d52fc 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -70,6 +70,9 @@ enum ieee80211_channel_flags {
IEEE80211_CHAN_NO_FAT_BELOW = 1<<5,
};
+#define IEEE80211_CHAN_NO_HT40 \
+ (IEEE80211_CHAN_NO_FAT_ABOVE | IEEE80211_CHAN_NO_FAT_BELOW)
+
/**
* struct ieee80211_channel - channel definition
*
@@ -1303,9 +1306,10 @@ extern void wiphy_apply_custom_regulatory(
* 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.
+ * @desired_bw_khz: the desired max bandwidth you want to use per
+ * channel. Note that this is still 20 MHz if you want to use HT40
+ * as HT40 makes use of two channels for its 40 MHz width bandwidth.
+ * If set to 0 we'll assume you want the standard 20 MHz.
* @reg_rule: the regulatory rule which we have for this frequency
*
* Use this function to get the regulatory rule for a specific frequency on
@@ -1320,7 +1324,9 @@ extern void wiphy_apply_custom_regulatory(
* freq_in_rule_band() for our current definition of a band -- this is purely
* subjective and right now its 802.11 specific.
*/
-extern int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth,
+extern int freq_reg_info(struct wiphy *wiphy,
+ u32 center_freq,
+ u32 desired_bw_khz,
const struct ieee80211_reg_rule **reg_rule);
/*