|
Linux Kernel
3.7.1
|
All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
|
Linux Kernel
3.7.1
|
#include <linux/kernel.h>#include <linux/export.h>#include <linux/slab.h>#include <linux/list.h>#include <linux/random.h>#include <linux/ctype.h>#include <linux/nl80211.h>#include <linux/platform_device.h>#include <linux/moduleparam.h>#include <net/cfg80211.h>#include "core.h"#include "reg.h"#include "regdb.h"#include "nl80211.h"Go to the source code of this file.
Data Structures | |
| struct | reg_beacon |
Macros | |
| #define | pr_fmt(fmt) KBUILD_MODNAME ": " fmt |
| #define | REG_DBG_PRINT(args...) |
| #define | ONE_GHZ_IN_KHZ 1000000 |
| #define | REG_INTERSECT 1 |
Variables | |
| struct ieee80211_regdomain * | cfg80211_regdomain |
| #define ONE_GHZ_IN_KHZ 1000000 |
DOC: Wireless regulatory infrastructure
The usual implementation is for a driver to read a device EEPROM to determine which regulatory domain it should be operating under, then looking up the allowable channels in a driver-local table and finally registering those channels in the wiphy structure.
Another set of compliance enforcement is for drivers to use their own compliance limits which can be stored on the EEPROM. The host driver or firmware may ensure these are used.
In addition to all this we provide an extra layer of regulatory conformance. For drivers which do not have any regulatory information CRDA provides the complete regulatory solution. For others it provides a community effort on further restrictions to enhance compliance.
Note: When number of rules –> infinity we will not be able to index on alpha2 any more, instead we'll probably have to rely on some SHA1 checksum of the regdomain for example.
| EXPORT_SYMBOL | ( | freq_reg_info | ) |
| EXPORT_SYMBOL | ( | wiphy_apply_custom_regulatory | ) |
| EXPORT_SYMBOL | ( | regulatory_hint | ) |
| int freq_reg_info | ( | struct wiphy * | wiphy, |
| u32 | center_freq, | ||
| u32 | desired_bw_khz, | ||
| const struct ieee80211_reg_rule ** | reg_rule | ||
| ) |
freq_reg_info - get regulatory information for the given frequency : the wiphy for which we want to process this rule for : Frequency in KHz for which we want regulatory information for : 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. : 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.
| module_param | ( | ieee80211_regdom | , |
| charp | , | ||
| 0444 | |||
| ) |
| int reg_device_uevent | ( | struct device * | dev, |
| struct kobj_uevent_env * | env | ||
| ) |
DOC: Regulatory enforcement infrastructure
TODO regulatory_hint - driver hint to the wireless core a regulatory domain : the wireless device giving the hint (used only for reporting conflicts) : the ISO/IEC 3166 alpha2 the driver claims its regulatory domain should be in. If is set this should be NULL. Note that if you set this to NULL you should still set rd->alpha2 to some accepted alpha2.
Wireless drivers can use this function to hint to the wireless core what it believes should be the current regulatory domain by giving it an ISO/IEC 3166 alpha2 country code it knows its regulatory domain should be in or by providing a completely build regulatory domain. If the driver provides an ISO/IEC 3166 alpha2 userspace will be queried for a regulatory domain structure for the respective country.
The wiphy must have been registered to cfg80211 prior to this call. For cfg80211 drivers this means you must first use wiphy_register(), for mac80211 drivers you must first use ieee80211_register_hw().
Drivers should check the return value, its possible you can get an -ENOMEM.
| void regulatory_hint_11d | ( | struct wiphy * | wiphy, |
| enum ieee80211_band | band, | ||
| u8 * | country_ie, | ||
| u8 | country_ie_len | ||
| ) |
regulatory_hint_11d - hints a country IE as a regulatory domain : the wireless device giving the hint (used only for reporting conflicts) : the band on which the country IE was received on. This determines the band we'll process the country IE channel triplets for. : pointer to the country IE : 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.
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.
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.
| int regulatory_hint_found_beacon | ( | struct wiphy * | wiphy, |
| struct ieee80211_channel * | beacon_chan, | ||
| gfp_t | gfp | ||
| ) |
regulatory_hint_found_beacon - hints a beacon was found on a channel : the wireless device where the beacon was found on : the channel on which the beacon was found on : 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 on a newly found BSS. If you cannot make use of this feature you can set the wiphy->disable_beacon_hints to true.
| int regulatory_hint_user | ( | const char * | alpha2, |
| enum nl80211_user_reg_hint_type | user_reg_hint_type | ||
| ) |
| void wiphy_apply_custom_regulatory | ( | struct wiphy * | wiphy, |
| const struct ieee80211_regdomain * | regd | ||
| ) |
wiphy_apply_custom_regulatory - apply a custom driver regulatory domain : the wireless device we want to process the regulatory domain on : 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.
| struct ieee80211_regdomain* cfg80211_regdomain |
1.8.2