1. 16 9月, 2010 1 次提交
    • A
      net/wireless: use generic_file_llseek in debugfs · 2b18ab36
      Arnd Bergmann 提交于
      The default llseek operation is changing from
      default_llseek to no_llseek, so all code relying on
      the current behaviour needs to make that explicit.
      
      The wireless driver infrastructure and some of the drivers
      make use of generated debugfs files, so they cannot
      be converted by our script that automatically determines
      the right operation.
      
      All these files use debugfs and they typically rely
      on simple_read_from_buffer, so the best llseek operation
      here is generic_file_llseek.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      2b18ab36
  2. 04 6月, 2010 1 次提交
  3. 09 2月, 2010 1 次提交
  4. 13 1月, 2010 1 次提交
  5. 19 11月, 2009 1 次提交
  6. 31 10月, 2009 1 次提交
    • J
      cfg80211/mac80211: use debugfs_remove_recursive · 7bcfaf2f
      Johannes Berg 提交于
      We can save a lot of code and pointers in the structs
      by using debugfs_remove_recursive().
      
      First, change cfg80211 to use debugfs_remove_recursive()
      so that drivers do not need to clean up any files they
      added to the per-wiphy debugfs (if and only if they are
      ok to be accessed until after wiphy_unregister!).
      
      Then also make mac80211 use debugfs_remove_recursive()
      where necessary -- it need not remove per-wiphy files
      as cfg80211 now removes those, but netdev etc. files
      still need to be handled but can now be removed without
      needing struct dentry pointers to all of them.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bcfaf2f
  7. 25 7月, 2009 1 次提交
  8. 16 6月, 2009 1 次提交
  9. 21 5月, 2009 1 次提交
  10. 14 5月, 2009 1 次提交
  11. 07 5月, 2009 1 次提交
  12. 23 4月, 2009 1 次提交
  13. 28 3月, 2009 1 次提交
  14. 30 1月, 2009 3 次提交
  15. 01 11月, 2008 2 次提交
  16. 16 9月, 2008 1 次提交
  17. 15 7月, 2008 1 次提交
  18. 08 5月, 2008 1 次提交
    • J
      mac80211: QoS related cleanups · e100bb64
      Johannes Berg 提交于
      This
       * makes the queue number passed to drivers a u16
         (as it will be with skb_get_queue_mapping)
       * removes the useless queue number defines
       * splits hw->queues into hw->queues/ampdu_queues
       * removes the debugfs files for per-queue counters
       * removes some dead QoS code
       * removes the beacon queue configuration for IBSS
         so that the drivers now never get a queue number
         bigger than (hw->queues + hw->ampdu_queues - 1)
         for tx and only in the range 0..hw->queues-1 for
         conf_tx.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e100bb64
  19. 09 4月, 2008 2 次提交
  20. 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
  21. 11 10月, 2007 4 次提交
  22. 12 6月, 2007 1 次提交
  23. 06 5月, 2007 1 次提交