1. 27 Mar, 2009 2 commits
    • Johannes Berg's avatar
      mac80211: fix aggregation to not require queue stop · cd8ffc80
      Johannes Berg authored
      
      
      Instead of stopping the entire AC queue when enabling aggregation
      (which was only done for hardware with aggregation queues) buffer
      the packets for each station, and release them to the pending skb
      queue once aggregation is turned on successfully.
      
      We get a little more code, but it becomes conceptually simpler and
      we can remove the entire virtual queue mechanism from mac80211 in
      a follow-up patch.
      
      This changes how mac80211 behaves towards drivers that support
      aggregation but have no hardware queues -- those drivers will now
      not be handed packets while the aggregation session is being
      established, but only after it has been fully established.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cd8ffc80
    • Sujith's avatar
      mac80211: Tear down aggregation sessions for suspend/resume · 722f069a
      Sujith authored
      
      
      When the driver has been notified with a STA_REMOVE, it tears down
      the internal ADDBA state. On resume, trying to initiate aggregation would
      fail because mac80211 has not cleared the operational state for that <TID,STA>.
      This can be fixed by tearing down the existing sessions on a suspend.
      
      Also, the driver can initiate a new BA session when suspend is in progress.
      This is fixed by marking the station as being in suspend state and
      denying ADDBA requests for such STAs.
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      722f069a
  2. 27 Feb, 2009 2 commits
    • Johannes Berg's avatar
      mac80211: add missing kernel-doc · 0a16ec5f
      Johannes Berg authored
      
      
      Document the new shutdown member.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0a16ec5f
    • Johannes Berg's avatar
      mac80211: fix aggregation for hardware with ampdu queues · 96f5e66e
      Johannes Berg authored
      
      
      Hardware with AMPDU queues currently has broken aggregation.
      
      This patch fixes it by making all A-MPDUs go over the regular AC queues,
      but keeping track of the hardware queues in mac80211. As a first rough
      version, it actually stops the AC queue for extended periods of time,
      which can be removed by adding buffering internal to mac80211, but is
      currently not a huge problem because people rarely use multiple TIDs
      that are in the same AC (and iwlwifi currently doesn't operate as AP).
      
      This is a short-term fix, my current medium-term plan, which I hope to
      execute soon as well, but am not sure can finish before .30, looks like
      this:
       1) rework the internal queuing layer in mac80211 that we use for
          fragments if the driver stopped queue in the middle of a fragmented
          frame to be able to queue more frames at once (rather than just a
          single frame with its fragments)
       2) instead of stopping the entire AC queue, queue up the frames in a
          per-station/per-TID queue during aggregation session initiation,
          when the session has come up take all those frames and put them
          onto the queue from 1)
       3) push the ampdu queue layer abstraction this patch introduces in
          mac80211 into the driver, and remove the virtual queue stuff from
          mac80211 again
      
      This plan will probably also affect ath9k in that mac80211 queues the
      frames instead of passing them down, even when there are no ampdu queues.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      96f5e66e
  3. 13 Feb, 2009 3 commits
  4. 29 Jan, 2009 2 commits
  5. 16 Jan, 2009 1 commit
  6. 21 Nov, 2008 1 commit
    • Randy Dunlap's avatar
      mac80211: remove more excess kernel-doc · 0ed94eaa
      Randy Dunlap authored
      
      
      Delete kernel-doc struct descriptions for fields that don't exist:
      
      Warning(include/net/mac80211.h:1263): Excess struct/union/enum/typedef member 'conf_ht' description in 'ieee80211_ops'
      Warning(net/mac80211/sta_info.h:309): Excess struct/union/enum/typedef member 'addr' description in 'sta_info'
      Warning(net/mac80211/sta_info.h:309): Excess struct/union/enum/typedef member 'aid' description in 'sta_info'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      cc: Johannes Berg <johannes@sipsolutions.net>
      cc: John W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0ed94eaa
  7. 31 Oct, 2008 2 commits
  8. 14 Oct, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: fix debugfs lockup · 63044e9f
      Johannes Berg authored
      
      
      When debugfs_create_dir fails, sta_info_debugfs_add_work will not
      terminate because it will find the same station again and again.
      This is possible whenever debugfs fails for whatever reason; one
      reason is a race condition in mac80211, unfortunately we cannot
      do much about it, so just document it, it just means some station
      may be missing from debugfs.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: Robin Holt <holt@sgi.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      63044e9f
  9. 30 Sep, 2008 1 commit
  10. 24 Sep, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: clean up rate control API · 4b7679a5
      Johannes Berg authored
      
      
      Long awaited, hard work. This patch totally cleans up the rate control
      API to remove the requirement to include internal headers outside of
      net/mac80211/.
      
      There's one internal use in the PID algorithm left for mesh networking,
      we'll have to figure out a way to clean that one up and decide how to
      do the peer link evaluation, possibly independent of the rate control
      algorithm or via new API.
      
      Additionally, ath9k is left using the cross-inclusion hack for now, we
      will add new API where necessary to make this work properly, but right
      now I'm not expert enough to do it. It's still off better than before.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4b7679a5
  11. 15 Sep, 2008 8 commits
  12. 08 Sep, 2008 1 commit
  13. 14 Jul, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: fix TX sequence numbers · f591fa5d
      Johannes Berg authored
      
      
      This patch makes mac80211 assign proper sequence numbers to
      QoS-data frames. It also removes the old sequence number code
      because we noticed that only the driver or hardware can assign
      sequence numbers to non-QoS-data and especially management
      frames in a race-free manner because beacons aren't passed
      through mac80211's TX path.
      
      This patch also adds temporary code to the rt2x00 drivers to
      not break them completely, that code will have to be reworked
      for proper sequence numbers on beacons.
      
      It also moves sequence number assignment down in the TX path
      so no sequence numbers are assigned to frames that are dropped.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f591fa5d
  14. 08 Jul, 2008 1 commit
  15. 26 Jun, 2008 1 commit
  16. 21 May, 2008 2 commits
  17. 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
    • Johannes Berg's avatar
      mac80211: proper STA info locking · 07346f81
      Johannes Berg authored
      
      
      As discussed earlier, we can unify locking in struct sta_info
      and use just a single spinlock protecting all members of the
      structure that need protection. Many don't, but one of the
      especially bad ones is the 'flags' member that can currently
      be clobbered when RX and TX is being processed on different
      CPUs at the same time.
      
      Because having four spinlocks for different, mostly exclusive
      parts of a single structure is overkill, this patch also kills
      the ampdu and mesh plink spinlocks and uses just a single one
      for everything. Because none of the spinlocks are nested, this
      is safe.
      
      It remains to be seen whether or not we should make the sta
      flags use atomic bit operations instead, for now though this
      is a safe thing and using atomic operations instead will be
      very simple using the new static inline functions this patch
      introduces for accessing sta->flags.
      
      Since spin_lock_bh() is used with this lock, there shouldn't
      be any contention even if aggregation is enabled at around the
      same time as both requires frame transmission/reception which
      is in a bh context.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: Tomas Winkler <tomasw@gmail.com>
      Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
      Cc: Luis Carlos Cobo <luisca@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      07346f81
  18. 08 Apr, 2008 2 commits
    • Johannes Berg's avatar
      mac80211: rename files · 2c8dccc7
      Johannes Berg authored
      
      
      This patch renames all mac80211 files (except ieee80211_i.h) to get rid
      of the useless ieee80211_ prefix.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2c8dccc7
    • Johannes Berg's avatar
      mac80211: fix key vs. sta locking problems · 3b96766f
      Johannes Berg authored
      
      
      Up to now, key manipulation is supposed to run under RTNL to
      avoid concurrent manipulations and also allow the set_key()
      hardware callback to sleep. This is not feasible because STA
      structs are rcu-protected and thus a lot of operations there
      cannot take the RTNL. Also, key references are rcu-protected
      so we cannot do things atomically.
      
      This patch changes key locking completely:
       * key operations are now atomic
       * hardware crypto offload is enabled and disabled from
         a workqueue, due to that key freeing is also delayed
       * debugfs code is also run from a workqueue
       * keys reference STAs (and vice versa!) so during STA
         unlink the STAs key reference is removed but not the
         keys STA reference, to avoid races key todo work is
         run before STA destruction.
       * fewer STA operations now need the RTNL which was
         required due to key operations
      
      This fixes the locking problems lockdep pointed out and also
      makes things more light-weight because the rtnl isn't required
      as much.
      
      Note that the key todo lock/key mutex are global locks, this
      is not required, of course, they could be per-hardware instead.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3b96766f
  19. 01 Apr, 2008 2 commits
  20. 27 Mar, 2008 3 commits
  21. 06 Mar, 2008 1 commit