1. 09 4月, 2010 1 次提交
  2. 11 3月, 2010 1 次提交
    • A
      mac80211: give warning if building w/out rate ctrl algorithm · c2ef355b
      Andres Salomon 提交于
      I discovered that if EMBEDDED=y, one can accidentally build a mac80211 stack
      and drivers w/ no rate control algorithm.  For drivers like RTL8187 that don't
      supply their own RC algorithms, this will cause ieee80211_register_hw to
      fail (making the driver unusable).
      
      This will tell kconfig to provide a warning if no rate control algorithms
      have been selected.  That'll at least warn the user; users that know that
      their drivers supply a rate control algorithm can safely ignore the
      warning, and those who don't know (or who expect to be using multiple
      drivers) can select a default RC algorithm.
      Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2ef355b
  3. 22 12月, 2009 1 次提交
  4. 12 11月, 2009 1 次提交
  5. 03 9月, 2009 1 次提交
  6. 14 8月, 2009 1 次提交
  7. 30 7月, 2009 1 次提交
  8. 25 7月, 2009 1 次提交
  9. 22 7月, 2009 1 次提交
    • J
      mac80211: disable mesh · e2e414d9
      Johannes Berg 提交于
      My kvm instance was complaining a lot about sleeping
      in atomic contexts in the mesh code, and it turns out
      that both mesh_path_add() and mpp_path_add() need to
      be able to sleep (they even use synchronize_rcu()!).
      I put in a might_sleep() to annotate that, but I see
      no way, at least right now, of actually making sure
      those functions are only called from process context
      since they are both called during TX and RX and the
      mesh code itself even calls them with rcu_read_lock()
      "held".
      
      Therefore, let's disable it completely for now.
      
      It's possible that I'm only seeing this because the
      hwsim's beaconing is broken and thus the peers aren't
      discovered right away, but it is possible that this
      happens even if beaconing is working, for a peer that
      doesn't exist or so.
      
      It should be possible to solve this by deferring the
      freeing of the tables to call_rcu() instead of using
      synchronize_rcu(), and also using atomic allocations,
      but maybe it makes more sense to rework the code to
      not call these from atomic contexts and defer more of
      the work to the workqueue. Right now, I can't work on
      either of those solutions though.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e2e414d9
  10. 11 7月, 2009 1 次提交
  11. 04 6月, 2009 1 次提交
  12. 23 4月, 2009 1 次提交
  13. 21 4月, 2009 1 次提交
  14. 30 3月, 2009 1 次提交
  15. 26 11月, 2008 1 次提交
  16. 07 10月, 2008 1 次提交
  17. 16 9月, 2008 1 次提交
  18. 18 7月, 2008 2 次提交
  19. 09 7月, 2008 2 次提交
  20. 03 7月, 2008 1 次提交
  21. 01 7月, 2008 2 次提交
    • 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
    • Y
      mac80211: add MAC80211_VERBOSE_SPECT_MGMT_DEBUG Kconfig option · 7b1e78d5
      Yi Zhu 提交于
      The patch introduces MAC80211_VERBOSE_SPECT_MGMT_DEBUG Kconfig option to
      suppress Spectrum Management 802.11h related debug logs.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7b1e78d5
  22. 27 6月, 2008 1 次提交
  23. 22 5月, 2008 1 次提交
  24. 28 4月, 2008 1 次提交
  25. 14 3月, 2008 1 次提交
  26. 07 3月, 2008 3 次提交
  27. 06 2月, 2008 1 次提交
  28. 02 2月, 2008 1 次提交
  29. 29 1月, 2008 5 次提交
  30. 11 11月, 2007 2 次提交