1. 18 Jun, 2011 2 commits
  2. 11 Jun, 2011 4 commits
  3. 03 Jun, 2011 1 commit
  4. 01 Jun, 2011 1 commit
  5. 13 May, 2011 2 commits
    • Johannes Berg's avatar
      iwlagn: support multiple TBs per command · 4ce7cc2b
      Johannes Berg authored
      The current "huge" command handling is a bit
      confusing, and very limited since only one
      command may be huge at a time. Additionally,
      we often copy data around quite pointlessly
      since we could instead map the existing scan
      buffer for example and use it directly.
      This patch makes that possible. The first
      change is that multiple buffers may be given
      to each command (this change was prepared
      earlier so callsites don't need to change).
      Each of those can be mapped attached to a TB
      in the TFD, and the command header can use a
      TB (the first one) in the TFD as well.
      Doing this allows getting rid of huge commands
      in favour of mapping existing buffers. The
      beacon transmission is also optimised to not
      copy the SKB at all but use multiple TBs.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
    • Johannes Berg's avatar
      iwlagn: prepare for multi-TB commands · 3fa50738
      Johannes Berg authored
      In a subsequent patch, I want to make commands use
      multiple TBs in a TFD. This is a simple change to
      prepare the data structures for this, with as of
      now still just a single TB supported.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
  6. 30 Apr, 2011 3 commits
  7. 22 Apr, 2011 7 commits
  8. 08 Apr, 2011 3 commits
    • Johannes Berg's avatar
      iwlagn: clean up & autodetect statistics · 0da0e5bf
      Johannes Berg authored
      There's no need to keep both normal and BT statistics
      versions around all the time in memory when we only
      use a subset of both. So keep only the subsets that
      we need in memory, depending on the debug config).
      Also, in doing so, we can remove all the calls to
      iwl_bt_statistics() in the driver as we'll just
      access the copied statistics now.
      Finally, also remove this call from the one place
      where it might still be needed and automatically
      detect what kind of statistics the device is sending
      based on their size. This way, we don't need to keep
      track of which devices do what any more, which is
      good since this is subject to change based on the
      ucode version (as some ucode even for non-BT devices
      will in fact use BT statistics).
      Warn upon encountering a statistics command from the
      ucode that isn't known, so we will find such issues
      earlier in the future.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Tested-by: default avatarDon Fry <donald.h.fry@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
    • Wey-Yi Guy's avatar
      iwlagn: tx power calib always done in firmware · ae89726a
      Wey-Yi Guy authored
      Remove the config flag for tx power calib
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
    • Garen Tamrazian's avatar
      iwlagn: fix radar frame rejection · 68b99311
      Garen Tamrazian authored
      The microcode may sometimes reject TX frames when
      on a radar channel even after we associated as it
      clears information during association and needs to
      receive a new beacon before allowing that channel
      again. This manifests itself as a TX status value
      of TX_STATUS_FAIL_PASSIVE_NO_RX. So in this case,
      stop the corresponding queue and give the frame
      back to mac80211 for retransmission. We start the
      queue again when a beacon from the AP is received
      which will make the regulatory enforcement in the
      device allow transmitting again.
      Signed-off-by: default avatarGaren Tamrazian <garenx.tamrazian@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
  9. 07 Apr, 2011 2 commits
  10. 25 Mar, 2011 1 commit
  11. 23 Mar, 2011 1 commit
  12. 11 Mar, 2011 1 commit
  13. 04 Mar, 2011 1 commit
  14. 03 Mar, 2011 1 commit
  15. 28 Feb, 2011 1 commit
  16. 26 Feb, 2011 3 commits
  17. 23 Feb, 2011 1 commit
  18. 11 Feb, 2011 1 commit
  19. 06 Feb, 2011 1 commit
  20. 31 Jan, 2011 2 commits
  21. 21 Jan, 2011 1 commit
    • Bruno Randolf's avatar
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf authored
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>