UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/net/wireless/reg.h

105 lines
4.4 KiB
C
Raw Normal View History

cfg80211: Add new wireless regulatory infrastructure This adds the new wireless regulatory infrastructure. The main motiviation behind this was to centralize regulatory code as each driver was implementing their own regulatory solution, and to replace the initial centralized code we have where: * only 3 regulatory domains are supported: US, JP and EU * regulatory domains can only be changed through module parameter * all rules were built statically in the kernel We now have support for regulatory domains for many countries and regulatory domains are now queried through a userspace agent through udev allowing distributions to update regulatory rules without updating the kernel. Each driver can regulatory_hint() a regulatory domain based on either their EEPROM mapped regulatory domain value to a respective ISO/IEC 3166-1 country code or pass an internally built regulatory domain. We also add support to let the user set the regulatory domain through userspace in case of faulty EEPROMs to further help compliance. Support for world roaming will be added soon for cards capable of this. For more information see: http://wireless.kernel.org/en/developers/Regulatory/CRDA For now we leave an option to enable the old module parameter, ieee80211_regdom, and to build the 3 old regdomains statically (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY. These old static definitions and the module parameter is being scheduled for removal for 2.6.29. Note that if you use this you won't make use of a world regulatory domain as its pointless. If you leave this option enabled and if CRDA is present and you use US or JP we will try to ask CRDA to update us a regulatory domain for us. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-10 14:19:48 +08:00
#ifndef __NET_WIRELESS_REG_H
#define __NET_WIRELESS_REG_H
cfg80211: relicense reg.c reg.h and genregdb.awk to ISC Following the tradition we have had with ath5k, ath9k, CRDA, wireless-regdb I'd like to license this code under the permissive ISC license for the code sharing purposes with other OSes, it'd sure be nice to help the landscape in this area. Although I am %82.89 owner of the regulatory code I have asked every contributor to the regulatory code and have receieved positive Acked-bys from everyone except two deceased entities: o Frans Pop RIP 2010 [0] - Frans Pop <elendil@planet.nl> - Frans Pop <fjp@debian.org> o Nokia RIP February, 11, 2011 [1], [2] - ext-yuri.ershov@nokia.com - kalle.valo@nokia.com Frans Pop's contribution was a simple patch 55f98938, titled, "wireless: remove trailing space in messages" which just add a \n to some printk lines. I'm going to treat these additions as uncopyrightable. As for the contributions made by employees on behalf of Nokia my contact point was Petri Karhula <petri.karhula@nokia.com> but after one month he noted he had not been able to get traction from the legal department on this request, as such it I proceeded by replacing their contributions in previous patches. The end goal is to help a clean rewrite that starts in userspace that is shared under ISC license which currently is taking place with the regulatory simulator [3]. [0] http://lists.debian.org/debian-devel/2011/12/msg00263.html [1] http://press.nokia.com/2011/02/11/nokia-outlines-new-strategy-introduces-new-leadership-operational-structure/ [2] http://NokiaPlanB.com [3] git://github.com/mcgrof/regsim.git Acked-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Acked-by: Dan Carpenter <error27@gmail.com> Acked-by: Mihai Moldovan <ionic@ionic.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Sven Neumann <s.neumann@raumfeld.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Acked-by: Tony Vroon <tony@linx.net> Acked-by: Pavel Roskin <proski@gnu.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Acked-by: Pat Erley <pat-lkml@erley.org> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: John W. Linville <linville@tuxdriver.com> Acked-by: Chris Wright <chrisw@sous-sol.org> Acked-by: Joe Perches <joe@perches.com> Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: John Gordon <john@devicescape.com> Acked-by: Simon Barber <protocolmagic@gmail.com> Acked-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by: Jiri Benc <jbenc@upir.cz> Acked-by: Bruno Randolf <br1@einfach.org> Acked-by: Scott James Remnant <keybuk@google.com> Acked-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 04:23:38 +08:00
/*
* Copyright 2008-2011 Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
cfg80211: Add new wireless regulatory infrastructure This adds the new wireless regulatory infrastructure. The main motiviation behind this was to centralize regulatory code as each driver was implementing their own regulatory solution, and to replace the initial centralized code we have where: * only 3 regulatory domains are supported: US, JP and EU * regulatory domains can only be changed through module parameter * all rules were built statically in the kernel We now have support for regulatory domains for many countries and regulatory domains are now queried through a userspace agent through udev allowing distributions to update regulatory rules without updating the kernel. Each driver can regulatory_hint() a regulatory domain based on either their EEPROM mapped regulatory domain value to a respective ISO/IEC 3166-1 country code or pass an internally built regulatory domain. We also add support to let the user set the regulatory domain through userspace in case of faulty EEPROMs to further help compliance. Support for world roaming will be added soon for cards capable of this. For more information see: http://wireless.kernel.org/en/developers/Regulatory/CRDA For now we leave an option to enable the old module parameter, ieee80211_regdom, and to build the 3 old regdomains statically (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY. These old static definitions and the module parameter is being scheduled for removal for 2.6.29. Note that if you use this you won't make use of a world regulatory domain as its pointless. If you leave this option enabled and if CRDA is present and you use US or JP we will try to ask CRDA to update us a regulatory domain for us. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-10 14:19:48 +08:00
regulatory: use RCU to protect global and wiphy regdomains To simplify the locking and not require cfg80211_mutex (which nl80211 uses to access the global regdomain) and also to make it possible for drivers to access their wiphy->regd safely, use RCU to protect these pointers. Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-06 22:47:38 +08:00
extern const struct ieee80211_regdomain __rcu *cfg80211_regdomain;
cfg80211: add get reg command This lets userspace request to get the currently set regulatory domain. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-01-31 01:26:42 +08:00
cfg80211: fix regulatory code const A few pointers and structures in the regulatory code are const, but because it wasn't done properly a whole bunch of bogus casts were needed to compile without warning. Mark everything const properly to avoid that kind of junk code. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-15 17:10:52 +08:00
bool is_world_regdom(const char *alpha2);
cfg80211: process regulatory DFS region for countries The wireless-regdb now has support for mapping a country to one DFS region. CRDA sends this to us now so process it so we can provide that hint to drivers. This will later be used by code for processing DFS in a way that meets the criteria for the DFS region the country belongs to. Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-10-12 01:59:02 +08:00
bool reg_supported_dfs_region(u8 dfs_region);
cfg80211: Add new wireless regulatory infrastructure This adds the new wireless regulatory infrastructure. The main motiviation behind this was to centralize regulatory code as each driver was implementing their own regulatory solution, and to replace the initial centralized code we have where: * only 3 regulatory domains are supported: US, JP and EU * regulatory domains can only be changed through module parameter * all rules were built statically in the kernel We now have support for regulatory domains for many countries and regulatory domains are now queried through a userspace agent through udev allowing distributions to update regulatory rules without updating the kernel. Each driver can regulatory_hint() a regulatory domain based on either their EEPROM mapped regulatory domain value to a respective ISO/IEC 3166-1 country code or pass an internally built regulatory domain. We also add support to let the user set the regulatory domain through userspace in case of faulty EEPROMs to further help compliance. Support for world roaming will be added soon for cards capable of this. For more information see: http://wireless.kernel.org/en/developers/Regulatory/CRDA For now we leave an option to enable the old module parameter, ieee80211_regdom, and to build the 3 old regdomains statically (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY. These old static definitions and the module parameter is being scheduled for removal for 2.6.29. Note that if you use this you won't make use of a world regulatory domain as its pointless. If you leave this option enabled and if CRDA is present and you use US or JP we will try to ask CRDA to update us a regulatory domain for us. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-10 14:19:48 +08:00
cfg80211: add cellular base station regulatory hint support Cellular base stations can provide hints to cfg80211 about where they think we are. This can be done for example on a cell phone. To enable these hints we simply allow them through as user regulatory hints but we allow userspace to clasify the hint as either coming directly from the user or coming from a cellular base station. This option is only available when you enable CONFIG_CFG80211_CERTIFICATION_ONUS. The base station hints themselves will not be processed by the core unless at least one device on the system supports this feature. Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-13 02:49:18 +08:00
int regulatory_hint_user(const char *alpha2,
enum nl80211_user_reg_hint_type user_reg_hint_type);
cfg80211: move all regulatory hints to workqueue All regulatory hints (core, driver, userspace and 11d) are now processed in a workqueue. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-02-21 13:04:30 +08:00
net/wireless: add COUNTRY to to regulatory device uevent Regulatory devices issue change uevents to inform userspace of a need to call the crda tool; however these can often be sent before udevd is running, and were not previously included in the results of udevadm trigger (which requests a new change event using the /uevent attribute of the sysfs object). Add a uevent function to the device type which includes the COUNTRY information from the last request if it has yet to be processed, the case of multiple requests is already handled in the code by checking whether an unprocessed one is queued in the same manner and refusing to queue a new one. The existing udev rule continues to work as before. Signed-off-by: Scott James Remnant <keybuk@google.com> Acked-By: Kay Sievers <kay.sievers@vrfy.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-03-09 02:45:30 +08:00
int reg_device_uevent(struct device *dev, struct kobj_uevent_env *env);
cfg80211: add cellular base station regulatory hint support Cellular base stations can provide hints to cfg80211 about where they think we are. This can be done for example on a cell phone. To enable these hints we simply allow them through as user regulatory hints but we allow userspace to clasify the hint as either coming directly from the user or coming from a cellular base station. This option is only available when you enable CONFIG_CFG80211_CERTIFICATION_ONUS. The base station hints themselves will not be processed by the core unless at least one device on the system supports this feature. Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-13 02:49:18 +08:00
void wiphy_regulatory_register(struct wiphy *wiphy);
cfg80211: rename reg_device_remove() to wiphy_regulatory_deregister() This makes it clearer what we're doing. This now makes a bit more sense given that regardless of the wiphy if the cell base station hint feature is supported we will be modifying the way the regulatory core behaves. Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-13 02:49:19 +08:00
void wiphy_regulatory_deregister(struct wiphy *wiphy);
cfg80211/mac80211: Add 802.11d support This adds country IE parsing to mac80211 and enables its usage within the new regulatory infrastructure in cfg80211. We parse the country IEs only on management beacons for the BSSID you are associated to and disregard the IEs when the country and environment (indoor, outdoor, any) matches the already processed country IE. To avoid following misinformed or outdated APs we build and use a regulatory domain out of the intersection between what the AP provides us on the country IE and what CRDA is aware is allowed on the same country. A secondary device is allowed to follow only the same country IE as it make no sense for two devices on a system to be in two different countries. In the case the AP is using country IEs for an incorrect country the user may help compliance further by setting the regulatory domain before or after the IE is parsed and in that case another intersection will be performed. CONFIG_WIRELESS_OLD_REGULATORY is supported but requires CRDA present. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-11-13 06:22:02 +08:00
wireless: move regulatory_init to .init.text regulatory_init is only called by cfg80211_init which is in .init.text, too. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-06-18 15:38:55 +08:00
int __init regulatory_init(void);
cfg80211: Add new wireless regulatory infrastructure This adds the new wireless regulatory infrastructure. The main motiviation behind this was to centralize regulatory code as each driver was implementing their own regulatory solution, and to replace the initial centralized code we have where: * only 3 regulatory domains are supported: US, JP and EU * regulatory domains can only be changed through module parameter * all rules were built statically in the kernel We now have support for regulatory domains for many countries and regulatory domains are now queried through a userspace agent through udev allowing distributions to update regulatory rules without updating the kernel. Each driver can regulatory_hint() a regulatory domain based on either their EEPROM mapped regulatory domain value to a respective ISO/IEC 3166-1 country code or pass an internally built regulatory domain. We also add support to let the user set the regulatory domain through userspace in case of faulty EEPROMs to further help compliance. Support for world roaming will be added soon for cards capable of this. For more information see: http://wireless.kernel.org/en/developers/Regulatory/CRDA For now we leave an option to enable the old module parameter, ieee80211_regdom, and to build the 3 old regdomains statically (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY. These old static definitions and the module parameter is being scheduled for removal for 2.6.29. Note that if you use this you won't make use of a world regulatory domain as its pointless. If you leave this option enabled and if CRDA is present and you use US or JP we will try to ask CRDA to update us a regulatory domain for us. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-10 14:19:48 +08:00
void regulatory_exit(void);
cfg80211: fix regulatory code const A few pointers and structures in the regulatory code are const, but because it wasn't done properly a whole bunch of bogus casts were needed to compile without warning. Mark everything const properly to avoid that kind of junk code. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-15 17:10:52 +08:00
int set_regdom(const struct ieee80211_regdomain *rd);
cfg80211: hold reg_mutex when updating regulatory The function wiphy_update_regulatory() uses the static variable last_request and thus needs to be called with reg_mutex held. This is the case for all users in reg.c, but the function was exported for use by wiphy_register(), from where it is called without the lock being held. Fix this by making wiphy_update_regulatory() private and introducing regulatory_update() as a wrapper that acquires and holds the lock. Signed-off-by: Sven Neumann <s.neumann@raumfeld.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Luis R. Rodriguez <mcgrof@gmail.com> Cc: Daniel Mack <daniel@zonque.org> Cc: linux-wireless@vger.kernel.org Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-08-31 05:38:53 +08:00
cfg80211: add cellular base station regulatory hint support Cellular base stations can provide hints to cfg80211 about where they think we are. This can be done for example on a cell phone. To enable these hints we simply allow them through as user regulatory hints but we allow userspace to clasify the hint as either coming directly from the user or coming from a cellular base station. This option is only available when you enable CONFIG_CFG80211_CERTIFICATION_ONUS. The base station hints themselves will not be processed by the core unless at least one device on the system supports this feature. Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-13 02:49:18 +08:00
bool reg_last_request_cell_base(void);
cfg80211: Add new wireless regulatory infrastructure This adds the new wireless regulatory infrastructure. The main motiviation behind this was to centralize regulatory code as each driver was implementing their own regulatory solution, and to replace the initial centralized code we have where: * only 3 regulatory domains are supported: US, JP and EU * regulatory domains can only be changed through module parameter * all rules were built statically in the kernel We now have support for regulatory domains for many countries and regulatory domains are now queried through a userspace agent through udev allowing distributions to update regulatory rules without updating the kernel. Each driver can regulatory_hint() a regulatory domain based on either their EEPROM mapped regulatory domain value to a respective ISO/IEC 3166-1 country code or pass an internally built regulatory domain. We also add support to let the user set the regulatory domain through userspace in case of faulty EEPROMs to further help compliance. Support for world roaming will be added soon for cards capable of this. For more information see: http://wireless.kernel.org/en/developers/Regulatory/CRDA For now we leave an option to enable the old module parameter, ieee80211_regdom, and to build the 3 old regdomains statically (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY. These old static definitions and the module parameter is being scheduled for removal for 2.6.29. Note that if you use this you won't make use of a world regulatory domain as its pointless. If you leave this option enabled and if CRDA is present and you use US or JP we will try to ask CRDA to update us a regulatory domain for us. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-10 14:19:48 +08:00
cfg80211: Add AP beacon regulatory hints When devices are world roaming they cannot beacon or do active scan on 5 GHz or on channels 12, 13 and 14 on the 2 GHz band. Although we have a good regulatory API some cards may _always_ world roam, this is also true when a system does not have CRDA present. Devices doing world roaming can still passive scan, if they find a beacon from an AP on one of the world roaming frequencies we make the assumption we can do the same and we also remove the passive scan requirement. This adds support for providing beacon regulatory hints based on scans. This works for devices that do either hardware or software scanning. If a channel has not yet been marked as having had a beacon present on it we queue the beacon hint processing into the workqueue. All wireless devices will benefit from beacon regulatory hints from any wireless device on a system including new devices connected to the system at a later time. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-02-21 13:20:39 +08:00
/**
* regulatory_hint_found_beacon - hints a beacon was found on a channel
* @wiphy: the wireless device where the beacon was found on
* @beacon_chan: the channel on which the beacon was found on
* @gfp: context flags
*
* This informs the wireless core that a beacon from an AP was found on
* the channel provided. This allows the wireless core to make educated
* guesses on regulatory to help with world roaming. This is only used for
* world roaming -- when we do not know our current location. This is
* only useful on channels 12, 13 and 14 on the 2 GHz band as channels
* 1-11 are already enabled by the world regulatory domain; and on
* non-radar 5 GHz channels.
*
* Drivers do not need to call this, cfg80211 will do it for after a scan
cfg80211: fix regression on beacon world roaming feature A regression was added through patch a4ed90d6: "cfg80211: respect API on orig_flags on channel for beacon hint" We did indeed respect _orig flags but the intention was not clearly stated in the commit log. This patch fixes firmware issues picked up by iwlwifi when we lift passive scan of beaconing restrictions on channels its EEPROM has been configured to always enable. By doing so though we also disallowed beacon hints on devices registering their wiphy with custom world regulatory domains enabled, this happens to be currently ath5k, ath9k and ar9170. The passive scan and beacon restrictions on those devices would never be lifted even if we did find a beacon and the hardware did support such enhancements when world roaming. Since Johannes indicates iwlwifi firmware cannot be changed to allow beacon hinting we set up a flag now to specifically allow drivers to disable beacon hints for devices which cannot use them. We enable the flag on iwlwifi to disable beacon hints and by default enable it for all other drivers. It should be noted beacon hints lift passive scan flags and beacon restrictions when we receive a beacon from an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz band. We don't bother with channels 1-11 as those channels are allowed world wide. This should fix world roaming for ath5k, ath9k and ar9170, thereby improving scan time when we receive the first beacon from any AP, and also enabling beaconing operation (AP/IBSS/Mesh) on cards which would otherwise not be allowed to do so. Drivers not using custom regulatory stuff (wiphy_apply_custom_regulatory()) were not affected by this as the orig_flags for the channels would have been cleared upon wiphy registration. I tested this with a world roaming ath5k card. Cc: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-31 08:43:48 +08:00
* on a newly found BSS. If you cannot make use of this feature you can
* set the wiphy->disable_beacon_hints to true.
cfg80211: Add AP beacon regulatory hints When devices are world roaming they cannot beacon or do active scan on 5 GHz or on channels 12, 13 and 14 on the 2 GHz band. Although we have a good regulatory API some cards may _always_ world roam, this is also true when a system does not have CRDA present. Devices doing world roaming can still passive scan, if they find a beacon from an AP on one of the world roaming frequencies we make the assumption we can do the same and we also remove the passive scan requirement. This adds support for providing beacon regulatory hints based on scans. This works for devices that do either hardware or software scanning. If a channel has not yet been marked as having had a beacon present on it we queue the beacon hint processing into the workqueue. All wireless devices will benefit from beacon regulatory hints from any wireless device on a system including new devices connected to the system at a later time. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-02-21 13:20:39 +08:00
*/
int regulatory_hint_found_beacon(struct wiphy *wiphy,
regulatory: code cleanup Clean up various things like indentation, extra parentheses, too many/few line breaks, etc. Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-04 00:21:11 +08:00
struct ieee80211_channel *beacon_chan,
gfp_t gfp);
cfg80211: Add AP beacon regulatory hints When devices are world roaming they cannot beacon or do active scan on 5 GHz or on channels 12, 13 and 14 on the 2 GHz band. Although we have a good regulatory API some cards may _always_ world roam, this is also true when a system does not have CRDA present. Devices doing world roaming can still passive scan, if they find a beacon from an AP on one of the world roaming frequencies we make the assumption we can do the same and we also remove the passive scan requirement. This adds support for providing beacon regulatory hints based on scans. This works for devices that do either hardware or software scanning. If a channel has not yet been marked as having had a beacon present on it we queue the beacon hint processing into the workqueue. All wireless devices will benefit from beacon regulatory hints from any wireless device on a system including new devices connected to the system at a later time. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-02-21 13:20:39 +08:00
cfg80211: enable country IE support to all cfg80211 drivers Since the bss is always set now once we are connected, if the bss has its own information element we refer to it and pass that instead of relying on mac80211's parsing. Now all cfg80211 drivers get country IE support, automatically and we reduce the call overhead that we had on mac80211 which called this upon every beacon and instead now call this only upon a successfull connection by a STA on cfg80211. Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-31 08:38:09 +08:00
/**
cfg80211: rename regulatory_hint_11d() to regulatory_hint_country_ie() It is incorrect to refer to this as 11d as 802.11d was just a proposed amendment, 802.11d was merged to the standard so use proper terminology. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-10-05 09:07:24 +08:00
* regulatory_hint_country_ie - hints a country IE as a regulatory domain
cfg80211: enable country IE support to all cfg80211 drivers Since the bss is always set now once we are connected, if the bss has its own information element we refer to it and pass that instead of relying on mac80211's parsing. Now all cfg80211 drivers get country IE support, automatically and we reduce the call overhead that we had on mac80211 which called this upon every beacon and instead now call this only upon a successfull connection by a STA on cfg80211. Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-31 08:38:09 +08:00
* @wiphy: the wireless device giving the hint (used only for reporting
* conflicts)
cfg80211: make regulatory_hint_11d() band specific In practice APs do not send country IE channel triplets for channels the AP is not operating on and if they were to do so they would have to use the regulatory extension which we currently do not process. No AP has been seen in practice that does this though so just drop those country IEs. Additionally it has been noted the first series of country IE channels triplets are specific to the band the AP sends. Propagate the band on which the country IE was found on reject the country IE then if the triplets are ever oustide of the band. Although we now won't process country IE information with multiple band information we leave the intersection work as is as it is technically possible for someone to want to eventually process these type of country IEs with regulatory extensions. Cc: Jouni Malinen <jouni.malinen@atheros.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-15 09:08:20 +08:00
* @band: the band on which the country IE was received on. This determines
* the band we'll process the country IE channel triplets for.
cfg80211: enable country IE support to all cfg80211 drivers Since the bss is always set now once we are connected, if the bss has its own information element we refer to it and pass that instead of relying on mac80211's parsing. Now all cfg80211 drivers get country IE support, automatically and we reduce the call overhead that we had on mac80211 which called this upon every beacon and instead now call this only upon a successfull connection by a STA on cfg80211. Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-31 08:38:09 +08:00
* @country_ie: pointer to the country IE
* @country_ie_len: length of the country IE
*
* We will intersect the rd with the what CRDA tells us should apply
* for the alpha2 this country IE belongs to, this prevents APs from
* sending us incorrect or outdated information against a country.
cfg80211: make regulatory_hint_11d() band specific In practice APs do not send country IE channel triplets for channels the AP is not operating on and if they were to do so they would have to use the regulatory extension which we currently do not process. No AP has been seen in practice that does this though so just drop those country IEs. Additionally it has been noted the first series of country IE channels triplets are specific to the band the AP sends. Propagate the band on which the country IE was found on reject the country IE then if the triplets are ever oustide of the band. Although we now won't process country IE information with multiple band information we leave the intersection work as is as it is technically possible for someone to want to eventually process these type of country IEs with regulatory extensions. Cc: Jouni Malinen <jouni.malinen@atheros.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-15 09:08:20 +08:00
*
* The AP is expected to provide Country IE channel triplets for the
* band it is on. It is technically possible for APs to send channel
* country IE triplets even for channels outside of the band they are
* in but for that they would have to use the regulatory extension
* in combination with a triplet but this behaviour is currently
* not observed. For this reason if a triplet is seen with channel
* information for a band the BSS is not present in it will be ignored.
cfg80211: enable country IE support to all cfg80211 drivers Since the bss is always set now once we are connected, if the bss has its own information element we refer to it and pass that instead of relying on mac80211's parsing. Now all cfg80211 drivers get country IE support, automatically and we reduce the call overhead that we had on mac80211 which called this upon every beacon and instead now call this only upon a successfull connection by a STA on cfg80211. Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-31 08:38:09 +08:00
*/
cfg80211: rename regulatory_hint_11d() to regulatory_hint_country_ie() It is incorrect to refer to this as 11d as 802.11d was just a proposed amendment, 802.11d was merged to the standard so use proper terminology. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-10-05 09:07:24 +08:00
void regulatory_hint_country_ie(struct wiphy *wiphy,
cfg80211: make regulatory_hint_11d() band specific In practice APs do not send country IE channel triplets for channels the AP is not operating on and if they were to do so they would have to use the regulatory extension which we currently do not process. No AP has been seen in practice that does this though so just drop those country IEs. Additionally it has been noted the first series of country IE channels triplets are specific to the band the AP sends. Propagate the band on which the country IE was found on reject the country IE then if the triplets are ever oustide of the band. Although we now won't process country IE information with multiple band information we leave the intersection work as is as it is technically possible for someone to want to eventually process these type of country IEs with regulatory extensions. Cc: Jouni Malinen <jouni.malinen@atheros.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-15 09:08:20 +08:00
enum ieee80211_band band,
cfg80211: fix BSS struct IE access races When a BSS struct is updated, the IEs are currently overwritten or freed. This can lead to races if some other CPU is accessing the BSS struct and using the IEs concurrently. Fix this by always allocating the IEs in a new struct that holds the data and length and protecting access to this new struct with RCU. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-29 08:25:20 +08:00
const u8 *country_ie,
cfg80211: enable country IE support to all cfg80211 drivers Since the bss is always set now once we are connected, if the bss has its own information element we refer to it and pass that instead of relying on mac80211's parsing. Now all cfg80211 drivers get country IE support, automatically and we reduce the call overhead that we had on mac80211 which called this upon every beacon and instead now call this only upon a successfull connection by a STA on cfg80211. Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-31 08:38:09 +08:00
u8 country_ie_len);
cfg80211: add regulatory hint disconnect support This adds a new regulatory hint to be used when we know all devices have been disconnected and idle. This can happen when we suspend, for instance. When we disconnect we can no longer assume the same regulatory rules learned from a country IE or beacon hints are applicable so restore regulatory settings to an initial state. Since driver hints are cached on the wiphy that called the hint, those hints are not reproduced onto cfg80211 as the wiphy will respect its own wiphy->regd regardless. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-30 08:58:57 +08:00
/**
* regulatory_hint_disconnect - informs all devices have been disconneted
*
* Regulotory rules can be enhanced further upon scanning and upon
* connection to an AP. These rules become stale if we disconnect
* and go to another country, whether or not we suspend and resume.
* If we suspend, go to another country and resume we'll automatically
* get disconnected shortly after resuming and things will be reset as well.
* This routine is a helper to restore regulatory settings to how they were
* prior to our first connect attempt. This includes ignoring country IE and
* beacon regulatory hints. The ieee80211_regdom module parameter will always
* be respected but if a user had set the regulatory domain that will take
* precedence.
*
* Must be called from process context.
*/
void regulatory_hint_disconnect(void);
cfg80211: Add new wireless regulatory infrastructure This adds the new wireless regulatory infrastructure. The main motiviation behind this was to centralize regulatory code as each driver was implementing their own regulatory solution, and to replace the initial centralized code we have where: * only 3 regulatory domains are supported: US, JP and EU * regulatory domains can only be changed through module parameter * all rules were built statically in the kernel We now have support for regulatory domains for many countries and regulatory domains are now queried through a userspace agent through udev allowing distributions to update regulatory rules without updating the kernel. Each driver can regulatory_hint() a regulatory domain based on either their EEPROM mapped regulatory domain value to a respective ISO/IEC 3166-1 country code or pass an internally built regulatory domain. We also add support to let the user set the regulatory domain through userspace in case of faulty EEPROMs to further help compliance. Support for world roaming will be added soon for cards capable of this. For more information see: http://wireless.kernel.org/en/developers/Regulatory/CRDA For now we leave an option to enable the old module parameter, ieee80211_regdom, and to build the 3 old regdomains statically (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY. These old static definitions and the module parameter is being scheduled for removal for 2.6.29. Note that if you use this you won't make use of a world regulatory domain as its pointless. If you leave this option enabled and if CRDA is present and you use US or JP we will try to ask CRDA to update us a regulatory domain for us. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-10 14:19:48 +08:00
#endif /* __NET_WIRELESS_REG_H */