packet: Kill CONFIG_PACKET_MMAP.

[safe/jmp/linux-2.6] / Documentation / networking / regulatory.txt

diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt
index 357d4ba..9551622 100644 (file)
--- a/Documentation/networking/regulatory.txt
+++ b/Documentation/networking/regulatory.txt
@@ -89,14 +89,14 @@ added to this document when its support is enabled.
 Device drivers who provide their own built regulatory domain
 do not need a callback as the channels registered by them are
 the only ones that will be allowed and therefore *additional*
-cannels cannot be enabled.
+channels cannot be enabled.
 
 Example code - drivers hinting an alpha2:
 ------------------------------------------
 
 This example comes from the zd1211rw device driver. You can start
 by having a mapping of your device's EEPROM country/regulatory
-domain value to to a specific alpha2 as follows:
+domain value to a specific alpha2 as follows:
 
 static struct zd_reg_alpha2_map reg_alpha2_map[] = {
        { ZD_REGDOMAIN_FCC, "US" },
@@ -131,11 +131,13 @@ are expected to do this during initialization.
 
        r = zd_reg2alpha2(mac->regdomain, alpha2);
        if (!r)
-               regulatory_hint(hw->wiphy, alpha2, NULL);
+               regulatory_hint(hw->wiphy, alpha2);
 
 Example code - drivers providing a built in regulatory domain:
 --------------------------------------------------------------
 
+[NOTE: This API is not currently available, it can be added when required]
+
 If you have regulatory information you can obtain from your
 driver and you *need* to use this we let you build a regulatory domain
 structure and pass it to the wireless core. To do this you should
@@ -182,6 +184,31 @@ Then in some part of your code after your wiphy has been registered:
        memcpy(rd, &mydriver_jp_regdom, sizeof(struct ieee80211_regdomain));
 
        for (i=0; i < num_rules; i++)
-               memcpy(&rd->reg_rules[i], &mydriver_jp_regdom.reg_rules[i],
-                       sizeof(struct ieee80211_reg_rule));
-       return regulatory_hint(hw->wiphy, NULL, rd);
+               memcpy(&rd->reg_rules[i],
+                      &mydriver_jp_regdom.reg_rules[i],
+                      sizeof(struct ieee80211_reg_rule));
+       regulatory_struct_hint(rd);
+
+Statically compiled regulatory database
+---------------------------------------
+
+In most situations the userland solution using CRDA as described
+above is the preferred solution.  However in some cases a set of
+rules built into the kernel itself may be desirable.  To account
+for this situation, a configuration option has been provided
+(i.e. CONFIG_CFG80211_INTERNAL_REGDB).  With this option enabled,
+the wireless database information contained in net/wireless/db.txt is
+used to generate a data structure encoded in net/wireless/regdb.c.
+That option also enables code in net/wireless/reg.c which queries
+the data in regdb.c as an alternative to using CRDA.
+
+The file net/wireless/db.txt should be kept up-to-date with the db.txt
+file available in the git repository here:
+
+    git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
+
+Again, most users in most situations should be using the CRDA package
+provided with their distribution, and in most other situations users
+should be building and using CRDA on their own rather than using
+this option.  If you are not absolutely sure that you should be using
+CONFIG_CFG80211_INTERNAL_REGDB then _DO_NOT_USE_IT_.