1. 14 2月, 2009 1 次提交
  2. 30 1月, 2009 2 次提交
  3. 13 12月, 2008 1 次提交
  4. 07 10月, 2008 1 次提交
  5. 12 9月, 2008 3 次提交
  6. 18 7月, 2008 1 次提交
  7. 01 7月, 2008 1 次提交
    • A
      build algorithms into the mac80211 module · e5f5e733
      Adrian Bunk 提交于
      The old infrastructure was:
      - the default algorithm is built into mac80211
      - other algorithms get into their own modules
      
      The implementation of this complicated scheme was horrible
      (just look at net/mac80211/Makefile), and anyone adding a new
      algorithm would most likely not get it right at his first attempt.
      
      This patch therefore builds all enabled algorithms into the mac80211
      module.
      
      The user interface for the rate control algorithms changes as follows:
      - first the user can choose which algorithms to enable (currently only
        MAC80211_RC_PID is available)
      - if more than one algorithm is enabled (currently not possible since
        only one algorithm is present) the user then chooses the default one
      
      Note:
      - MAC80211_RC_PID is always enables for CONFIG_EMBEDDED=n
      
      Technical changes:
      - all selected algorithms get into the mac80211 module
      - net/mac80211/Makefile can now become much less complicated
      - support for rc80211_pid_algo.c being modular is no longer required
      - this includes unexporting mesh_plink_broken
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5f5e733
  8. 22 5月, 2008 1 次提交
  9. 09 4月, 2008 1 次提交
  10. 14 3月, 2008 1 次提交
  11. 07 3月, 2008 1 次提交
  12. 01 3月, 2008 1 次提交
    • J
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg 提交于
      This patch creates new cfg80211 wiphy API for channel and bitrate
      registration and converts mac80211 and drivers to the new API. The
      old mac80211 API is completely ripped out. All drivers (except ath5k)
      are updated to the new API, in many cases I expect that optimisations
      can be done.
      
      Along with the regulatory code I've also ripped out the
      IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
      unnecessary if the hardware simply gives us whatever channels it wants
      to support and we then enable/disable them as required, which is pretty
      much required for travelling.
      
      Additionally, the patch adds proper "basic" rate handling for STA
      mode interface, AP mode interface will have to have new API added
      to allow userspace to set the basic rate set, currently it'll be
      empty... However, the basic rate handling will need to be moved to
      the BSS conf stuff.
      
      I do expect there to be bugs in this, especially wrt. transmit
      power handling where I'm basically clueless about how it should work.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  13. 29 1月, 2008 4 次提交
  14. 11 11月, 2007 1 次提交
  15. 11 10月, 2007 7 次提交
  16. 18 7月, 2007 1 次提交
    • D
      [PATCH] mac80211: regulatory domain cleanup · fd8bacc9
      Daniel Drake 提交于
      Currently, a function misnamed ieee80211_init_client() is used to handle
      regulatory domain control. It is called from
      ieee80211_register_hwmode(), which typically runs 2 or 3 times
      (802.11a/b/g), but each time it iterates over all the modes.
      
      This patch cleans this up and removes the confusion:
      ieee80211_init_client was effectively renamed to
      ieee80211_set_default_regdomain and is now run on a per-mode basis
      (doesn't have to deal with netdevs). I also moved the regdomain handling
      code into its own file and added some documentation.
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Acked-by: NJiri Benc <jbenc@suse.cz>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fd8bacc9
  17. 06 5月, 2007 2 次提交