diff options
author | Luis R. Rodriguez <lrodriguez@atheros.com> | 2009-05-02 06:37:17 +0200 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2009-05-20 20:46:22 +0200 |
commit | 038659e7c6b385065cb223872771ac437ef70b62 (patch) | |
tree | df9e86adcc611d10ed5f98672421bffe1f43989f /net/wireless/ibss.c | |
parent | sfc: Remove lro module parameter (diff) | |
download | linux-038659e7c6b385065cb223872771ac437ef70b62.tar.xz linux-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 'net/wireless/ibss.c')
0 files changed, 0 insertions, 0 deletions