1. 20 4月, 2010 1 次提交
  2. 09 4月, 2010 1 次提交
  3. 20 2月, 2010 1 次提交
  4. 09 2月, 2010 1 次提交
  5. 23 1月, 2010 1 次提交
    • J
      cfg80211: export multiple MAC addresses in sysfs · ef15aac6
      Johannes Berg 提交于
      If a device has multiple MAC addresses, userspace will
      need to know about that. Similarly, if it allows the
      MAC addresses to vary by a bitmask.
      
      If a driver exports multiple addresses, it is assumed
      that it will be able to deal with that many different
      addresses, which need not necessarily match the ones
      programmed into the device; if a mask is set then the
      device should deal addresses within that mask based
      on an arbitrary "base address".
      
      To test it all and show how it is used, add support
      to hwsim even though it can't actually deal with
      addresses different from the default.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ef15aac6
  6. 29 12月, 2009 2 次提交
  7. 23 12月, 2009 3 次提交
  8. 20 11月, 2009 1 次提交
  9. 03 11月, 2009 2 次提交
  10. 31 10月, 2009 1 次提交
  11. 30 9月, 2009 1 次提交
  12. 01 9月, 2009 1 次提交
  13. 20 8月, 2009 1 次提交
    • J
      mac80211: allow configure_filter callback to sleep · 3ac64bee
      Johannes Berg 提交于
      Over time, a whole bunch of drivers have come up
      with their own scheme to delay the configure_filter
      operation to a workqueue. To be able to simplify
      things, allow configure_filter to sleep, and add
      a new prepare_multicast callback that drivers that
      need the multicast address list implement. This new
      callback must be atomic, but most drivers either
      don't care or just calculate a hash which can be
      done atomically and then uploaded to the hardware
      non-atomically.
      
      A cursory look suggests that at76c50x-usb, ar9170,
      mwl8k (which is actually very broken now), rt2x00,
      wl1251, wl1271 and zd1211 should make use of this
      new capability.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ac64bee
  14. 25 7月, 2009 2 次提交
  15. 22 7月, 2009 2 次提交
  16. 11 7月, 2009 5 次提交
  17. 09 7月, 2009 1 次提交
  18. 06 7月, 2009 1 次提交
  19. 04 6月, 2009 1 次提交
  20. 21 5月, 2009 1 次提交
    • D
      mac80211_hwsim: Group radios · 73606d00
      Daniel Wagner 提交于
      Currently all radios receive all traffic on the simulated air
      if they are tuned to the same channel. This patch introduces
      the concept of grouping, which allows to assign a radio to
      certain group. Only radios in the same group can 'see' each other.
      
      Each bit in /debug/ieee80211/phy*/hwsim/group
      represents one group. By default all radios belong to the same group "1",
      e.g. bit 1 is set. Additionally a radio can belong to several groups.
      Signed-off-by: NDaniel Wagner <wagi@monom.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      73606d00
  21. 12 5月, 2009 1 次提交
  22. 07 5月, 2009 4 次提交
    • J
      mac80211: tell driver when idle · 5cff20e6
      Johannes Berg 提交于
      When we aren't doing anything in mac80211, we can turn off
      much of the hardware, depending on the driver/hw. Not doing
      anything, aka being idle, means:
      
       * no monitor interfaces
       * no AP/mesh/wds interfaces
       * any station interfaces are in DISABLED state
       * any IBSS interfaces aren't trying to be in a network
       * we aren't trying to scan
      
      By creating a new function that verifies these conditions and calling
      it at strategic points where the states of those conditions change,
      we can easily make mac80211 tell the driver when we are idle to save
      power.
      
      Additionally, this fixes a small quirk where a recalculated powersave
      state is passed to the driver even if the hardware is about to stopped
      completely.
      
      This patch intentionally doesn't touch radio_enabled because that is
      currently implemented to be a soft rfkill which is inappropriate here
      when we need to be able to wake up with low latency.
      
      One thing I'm not entirely sure about is this:
      
        phy0: device no longer idle - in use
        wlan0: direct probe to AP 00:11:24:91:07:4d try 1
        wlan0 direct probe responded
        wlan0: authenticate with AP 00:11:24:91:07:4d
        wlan0: authenticated
      > phy0: device now idle
      > phy0: device no longer idle - in use
        wlan0: associate with AP 00:11:24:91:07:4d
        wlan0: RX AssocResp from 00:11:24:91:07:4d (capab=0x401 status=0 aid=1)
        wlan0: associated
      
      Is it appropriate to go into idle state for a short time when we have
      just authenticated, but not associated yet? This happens only with the
      userspace SME, because we cannot really know how long it will wait
      before asking us to associate. Would going idle after a short timeout
      be more appropriate? We may need to revisit this, depending on what
      happens.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5cff20e6
    • J
      mac80211_hwsim: fix bogus warning · d91f190c
      Johannes Berg 提交于
      A typo slipped into my patch to configure beacon intervals
      properly -- this warning is supposed to trigger when the
      beacon interval is zero, not non-zero.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d91f190c
    • J
      mac80211: unify config_interface and bss_info_changed · 2d0ddec5
      Johannes Berg 提交于
      The config_interface method is a little strange, it contains the
      BSSID and beacon updates, while bss_info_changed contains most
      other BSS information for each interface. This patch removes
      config_interface and rolls all the information it previously
      passed to drivers into bss_info_changed.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2d0ddec5
    • J
      mac80211: clean up beacon interval settings · 57c4d7b4
      Johannes Berg 提交于
      We currently have two beacon interval configuration knobs:
      hw.conf.beacon_int and vif.bss_info.beacon_int. This is
      rather confusing, even though the former is used when we
      beacon ourselves and the latter when we are associated to
      an AP.
      
      This just deprecates the hw.conf.beacon_int setting in favour
      of always using vif.bss_info.beacon_int. Since it touches all
      the beaconing IBSS code anyway, we can also add support for
      the cfg80211 IBSS beacon interval configuration easily.
      
      NOTE: The hw.conf.beacon_int setting is retained for now due
            to drivers still using it -- I couldn't untangle all
            drivers, some are updated in this patch.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      57c4d7b4
  23. 28 3月, 2009 2 次提交
  24. 22 3月, 2009 1 次提交
  25. 17 3月, 2009 2 次提交