Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 11月, 2008 1 次提交
  3. 27 10月, 2008 1 次提交
  5. 15 10月, 2008 1 次提交
  7. 13 10月, 2008 1 次提交
  9. 07 10月, 2008 1 次提交
  11. 25 9月, 2008 8 次提交
  13. 16 9月, 2008 1 次提交
    • L
      cfg80211: Add new wireless regulatory infrastructure · b2e1b302
      由 Luis R. Rodriguez 提交于 
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b2e1b302
  15. 06 9月, 2008 1 次提交
  17. 03 9月, 2008 1 次提交
  19. 30 8月, 2008 2 次提交
  21. 13 8月, 2008 1 次提交
  23. 30 7月, 2008 1 次提交
  25. 20 7月, 2008 1 次提交
  27. 15 7月, 2008 1 次提交
  29. 09 7月, 2008 1 次提交
    • J
      net/wireless/nl80211.c: fix endless Netlink callback loop. · b4637271
      由 Julius Volz 提交于 
      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: NJulius Volz <juliusv@google.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b4637271
  31. 25 6月, 2008 1 次提交
  33. 17 6月, 2008 10 次提交
  35. 15 6月, 2008 1 次提交
  37. 04 6月, 2008 1 次提交
  39. 15 5月, 2008 2 次提交
  41. 09 4月, 2008 1 次提交
  43. 08 4月, 2008 1 次提交