1. 24 Sep, 2008 3 commits
  2. 15 Sep, 2008 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: Add new wireless regulatory infrastructure · b2e1b302
      Luis R. Rodriguez authored
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b2e1b302
  3. 05 Sep, 2008 1 commit
  4. 29 Aug, 2008 2 commits
  5. 29 Jul, 2008 1 commit
  6. 08 Jul, 2008 1 commit
    • Julius Volz's avatar
      net/wireless/nl80211.c: fix endless Netlink callback loop. · b4637271
      Julius Volz authored
      
      
      Although I only tested similar code (I don't use any of this wireless
      code), the state maintainance between Netlink dump callback invocations
      seems wrong here and should lead to an endless loop. There are also other
      examples in the same file which might have the same problem. Perhaps someone
      can actually test this (or refute my logic).
      
      Take the simple example with only one element in the list (which should fit
      into the message):
      
      1. invocation:
        Start:
          idx = 0, start = 0
        Loop:
          condition (++idx < start) => (1 < 0) => false
          => no continue, fill one entry, exit loop, return skb->len > 0
      
      2. invocation:
        Start:
          idx = 0, start = 1
        Loop:
          condition (++idx < start) => (1 < 1) => false
          => no continue, fill the same entry again, exit loop, return skb->len > 0
      
      3. invocation:
        Same as 2. invocation, endless invocation of callback.
      
      Also, iterations where the filling of an element fails should not be counted as
      completed, so idx should not be incremented in this case.
      
      Signed-off-by: default avatarJulius Volz <juliusv@google.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b4637271
  7. 03 Jun, 2008 1 commit
  8. 07 Apr, 2008 1 commit
  9. 06 Mar, 2008 1 commit
  10. 29 Feb, 2008 2 commits
  11. 28 Jan, 2008 4 commits
  12. 10 Oct, 2007 1 commit