summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/regd.c
AgeCommit message (Collapse)AuthorFilesLines
2010-04-07ath: fix code readability in regd.cLuis de Bethencourt1-1/+2
This is a patch to the ath/regd.c file that fixes two code readability issues. A space between to separate two defines and the indentation inside the ath_redg_is_eeprom_valid function. Signed-off-by: Luis de Bethencourt <luisbg@ubuntu.com> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-02-09ath: fix WARN_ON with Polish (Poland) Contry codeChristian Lamparter1-2/+3
This patch fixes a WARN_ON which is triggered by Poland's country code. ath: EEPROM regdomain: 0x8268 ath: EEPROM indicates we should expect a country code ath: doing EEPROM country->regdmn map search ath: country maps to regdmn code: 0x37 ath: Country alpha2 being used: PL ath: Regpair used: 0x37 -----------[ cut here ]------------ WARNING: at drivers/net/wireless/ath/regd.c:155 ath_regd_init+0x30b Pid: 12661, comm: firmware/carl91 2.6.33-rc5-wl #18 Call Trace: [<>] ? warn_slowpath_common+0x76/0x8c [<>] ? ar9170_reg_notifier+0x0/0x2d [carl9170usb] [<>] ? ath_regd_init+0x30b/0x377 [ath] [<>] ? ar9170_register+0x3b3/0x3ca [carl9170usb] [...] ---[ end trace ]--- Note: Poland is just an example. But it is very likely that more country codes are affected. Cc: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-19cfg80211: convert bools into flagsJohannes Berg1-3/+2
We've accumulated a number of options for wiphys which make more sense as flags as we keep adding more. Convert the existing ones. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-24Merge branch 'master' of ↵David S. Miller1-0/+17
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/iwmc3200wifi/netdev.c net/wireless/scan.c
2009-07-21ath: add support for special 0x8000 regulatory domainLuis R. Rodriguez1-0/+17
Two users of ar9170 devices have now reported their cards have been programmed with a regulatory domain of 0x8000. This is not a valid regulatory domain as such these users were unable to use these devices. Since this doesn't seem to be a device EEPROM corruption we must treat it specially. It may have been possible the manufacturer intended to use 0x0 as the regulatory domain and that would ultimately yield to US but since we cannot get confirmationf or this we default this special case to one of our world regulatory domains, specifically 0x64. Reported-by: DavidFreeman on #linux-wireless Reported-by: Joerg Albert <jal2@gmx.de> Cc: Christian Lamparter <chunkeey@web.de>, Cc: Stephen Chen <stephen.chen@atheros.com> Cc: David Quan <david.quan@atheros.com> Cc: Tony Yang <tony.yang@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-10ath: remove unnecessary return in ath_regd_get_band_ctlBob Copeland1-2/+0
'default' case already returns NO_CTL Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath: make regulatory parsing more verbose on debugLuis R. Rodriguez1-4/+25
This should help when reviewing issues regarding regulatory domain on ath5k/ath9k/ar9170. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20cfg80211: Process regulatory max bandwidth checks for HT40Luis R. Rodriguez1-4/+6
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>
2009-04-23cfg80211: clean up includesJohannes Berg1-1/+0
Trying to separate header files into net/wireless.h and net/cfg80211.h has been a source of confusion. Remove net/wireless.h (because there also is the linux/wireless.h) and subsume everything into net/cfg80211.h -- except the definitions for regulatory structures which get moved to a new header net/regulatory.h. The "new" net/cfg80211.h is now divided into sections. There are no real changes in this patch but code shuffling and some very minor documentation fixes. I have also, to make things reflect reality, put in a copyright line for Luis to net/regulatory.h since that is probably exclusively written by him but was formerly in a file that only had my copyright line. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-23atheros: fix propagation of bad EEPROM on regulatory initLuis R. Rodriguez1-1/+1
When the EEPROM is not in good condition we cannot continue so we currently bail out but only ath5k is bailing out properly. Both ath9k and ar9170 were proceeding and if a user were to run into this they'd see an obscure panic. Lets propagate the error as intended and make sure we inform the user by lifting the error message from debug to a kernel error. Stable note: You can find a port of this page here: http://bombadil.infradead.org/~mcgrof/patches/ath9k/ath9k-fix-eeprom.patch.txt Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-23ath: space cleanupLuis R. Rodriguez1-14/+19
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-23ath: move more setup code into ath_regd_initBob Copeland1-13/+42
Setup the wiphy regulatory parameters when first initializing the Atheros regulatory module. We can remove five exported symbols this way and simplify the driver code for both ath5k and ath9k. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-23atheros: introduce ath module containing common ath5k/ath9k/ar9170 codeBob Copeland1-0/+519
This change creates a new module, ath.ko, which includes code that can be shared between ath5k, ath9k and ar9170. For now, extract most of the ath9k regulatory code so it can also be used in ath5k. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>