1. 10 Jul, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: push rx status into skb->cb · f1d58c25
      Johannes Berg authored
      
      
      Within mac80211, we often need to copy the rx status into
      skb->cb. This is wasteful, as drivers could be building it
      in there to start with. This patch changes the API so that
      drivers are expected to pass the RX status in skb->cb, now
      accessible as IEEE80211_SKB_RXCB(skb). It also updates all
      drivers to pass the rx status in there, but only by making
      them memcpy() it into place before the call to the receive
      function (ieee80211_rx(_irqsafe)). Each driver can now be
      optimised on its own schedule.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f1d58c25
  2. 20 May, 2009 1 commit
  3. 06 May, 2009 1 commit
  4. 16 Mar, 2009 1 commit
  5. 05 Mar, 2009 1 commit
  6. 27 Feb, 2009 1 commit
  7. 13 Feb, 2009 2 commits
  8. 09 Feb, 2009 1 commit
  9. 08 Jan, 2009 1 commit
  10. 05 Dec, 2008 1 commit
    • Shaddy Baddah's avatar
      zd1211rw: use unaligned safe memcmp() in-place of compare_ether_addr() · cde6901b
      Shaddy Baddah authored
      
      
      Under my 2.6.28-rc6 sparc64, when associating to an AP through my
      zd1211rw device, I was seeing kernel log messages like (not exact output):
      
        Kernel unaligned access at TPC[10129b68] zd_mac_rx+0x144/0x32c [zd1211rw]
      
      For the zd1211rw module, on RX, the 80211 packet will be located after
      the PLCP header in the skb data buffer. The PLCP header being 5 bytes
      long, the 80211 header will start unaligned from an aligned skb
      buffer.
      
      As per Documentation/unaligned-memory-access.txt, we must replace the
      not unaligned() safe compare_ether_addr() with memcmp() to protect
      architectures that require alignment.
      Signed-off-by: default avatarShaddy Baddah <shaddy_baddah@hotmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cde6901b
  11. 31 Oct, 2008 3 commits
  12. 27 Oct, 2008 1 commit
  13. 23 Sep, 2008 1 commit
  14. 15 Sep, 2008 2 commits
  15. 05 Sep, 2008 1 commit
  16. 29 Jul, 2008 1 commit
  17. 14 Jul, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: revamp beacon configuration · 9d139c81
      Johannes Berg authored
      
      
      This patch changes mac80211's beacon configuration handling
      to never pass skbs to the driver directly but rather always
      require the driver to use ieee80211_beacon_get(). Additionally,
      it introduces "change flags" on the config_interface() call
      to enable drivers to figure out what is changing. Finally, it
      removes the beacon_update() driver callback in favour of
      having IBSS beacon delivered by ieee80211_beacon_get() as well.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9d139c81
  18. 09 Jul, 2008 1 commit
  19. 08 Jul, 2008 1 commit
  20. 26 Jun, 2008 1 commit
  21. 09 Jun, 2008 1 commit
  22. 22 May, 2008 1 commit
  23. 21 May, 2008 3 commits
  24. 14 May, 2008 2 commits
    • Bruno Randolf's avatar
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf authored
      
      
      trying to clean up the signal/noise code. the previous code in mac80211 had
      confusing names for the related variables, did not have much definition of
      what units of signal and noise were provided and used implicit mechanisms from
      the wireless extensions.
      
      this patch introduces hardware capability flags to let the hardware specify
      clearly if it can provide signal and noise level values and which units it can
      provide. this also anticipates possible new units like RCPI in the future.
      
      for signal:
      
        IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
        IEEE80211_HW_SIGNAL_DB     - dB difference to unspecified reference point
        IEEE80211_HW_SIGNAL_DBM    - dBm, difference to 1mW
      
      for noise we currently only have dBm:
      
        IEEE80211_HW_NOISE_DBM     - dBm, difference to 1mW
      
      if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
      to provide the maximum value (max_signal) it reports in order for applications
      to make sense of the signal values.
      
      i tried my best to find out for each driver what it can provide and update it
      but i'm not sure (?) for some of them and used the more conservative guess in
      doubt. this can be fixed easily after this patch has been merged by changing
      the hardware flags of the driver.
      
      DRIVER          SIGNAL    MAX	NOISE   QUAL
      -----------------------------------------------------------------
      adm8211         unspec(?) 100   n/a     missing
      at76_usb        unspec(?) (?)   unused  missing
      ath5k           dBm             dBm     percent rssi
      b43legacy       dBm             dBm     percent jssi(?)
      b43             dBm             dBm     percent jssi(?)
      iwl-3945        dBm             dBm     percent snr+more
      iwl-4965        dBm             dBm     percent snr+more
      p54             unspec    127   n/a     missing
      rt2x00          dBm	        n/a     percent rssi+tx/rx frame success
        rt2400        dBm             n/a
        rt2500pci     dBm             n/a
        rt2500usb     dBm             n/a
        rt61pci       dBm             n/a
        rt73usb       dBm             n/a
      rtl8180         unspec(?) 65    n/a     (?)
      rtl8187         unspec(?) 65    (?)     noise(?)
      zd1211          dB(?)     100   n/a     percent
      
      drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      566bfe5a
    • Bruno Randolf's avatar
      zd1211rw: initial IBSS support · 84e6dc9a
      Bruno Randolf authored
      
      
      this adds initial IBSS support for the zydas zd1211rw:
      convince driver that it can do IBSS mode. add mac80211 beacon_update callback.
      
      IBSS merge and TSF updates don't work yet, but it makes the driver usable in
      ad-hoc networks.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      84e6dc9a
  25. 06 Mar, 2008 1 commit
  26. 29 Feb, 2008 2 commits
    • Michael Buesch's avatar
      zd1211rw: Fix beacon filter flags thinko · 2c1a1b12
      Michael Buesch authored
      
      
      We must not clear the FIF_BCN_PRBRESP_PROMISC bit in the
      new_flags. The zd-driver does support sending beacons and
      probe responses to the host. What the flag does is say "Send me
      all beacons and probe responses". And we actually do that. We always
      do that, so we ignore the case when the bit is disabled. But that is
      fine. But we must not clear the flag, as that tells mac80211 that
      we do not support passing beacons and probe responses to the stack.
      And that's not true.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2c1a1b12
    • Johannes Berg's avatar
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  27. 20 Feb, 2008 1 commit
  28. 28 Jan, 2008 5 commits