Skip to content
Snippets Groups Projects
  1. Apr 08, 2010
  2. Feb 19, 2010
  3. Feb 08, 2010
  4. Jan 22, 2010
    • Johannes Berg's avatar
      cfg80211: export multiple MAC addresses in sysfs · ef15aac6
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ef15aac6
  5. Dec 28, 2009
  6. Dec 22, 2009
  7. Nov 19, 2009
  8. Nov 02, 2009
  9. Oct 30, 2009
  10. Sep 29, 2009
  11. Sep 01, 2009
  12. Aug 20, 2009
    • Johannes Berg's avatar
      mac80211: allow configure_filter callback to sleep · 3ac64bee
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3ac64bee
  13. Jul 24, 2009
  14. Jul 21, 2009
  15. Jul 10, 2009
  16. Jul 08, 2009
  17. Jul 05, 2009
  18. Jun 03, 2009
  19. May 20, 2009
    • Daniel Wagner's avatar
      mac80211_hwsim: Group radios · 73606d00
      Daniel Wagner authored
      
      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: default avatarDaniel Wagner <wagi@monom.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      73606d00
  20. May 11, 2009
  21. May 06, 2009
    • Johannes Berg's avatar
      mac80211: tell driver when idle · 5cff20e6
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5cff20e6
    • Johannes Berg's avatar
      mac80211_hwsim: fix bogus warning · d91f190c
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d91f190c
    • Johannes Berg's avatar
      mac80211: unify config_interface and bss_info_changed · 2d0ddec5
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2d0ddec5
    • Johannes Berg's avatar
      mac80211: clean up beacon interval settings · 57c4d7b4
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      57c4d7b4
  22. Mar 27, 2009
  23. Mar 21, 2009
  24. Mar 16, 2009
  25. Jan 29, 2009
Loading