1. 29 Aug, 2011 2 commits
  2. 08 Aug, 2011 3 commits
  3. 21 Jul, 2011 3 commits
  4. 16 Jul, 2011 4 commits
  5. 11 Jul, 2011 8 commits
  6. 01 Jul, 2011 2 commits
  7. 27 Jun, 2011 1 commit
    • Evgeni Golov's avatar
      iwlagn: fix *_UCODE_API_MAX output in the firmware field · 8fcbd4dc
      Evgeni Golov authored
      Currently (3.0-rc2), modinfo iwlagn shows:
          firmware:       iwlwifi-5150-IWL5150_UCODE_API_MAX.ucode
          firmware:       iwlwifi-5000-IWL5000_UCODE_API_MAX.ucode
          firmware:       iwlwifi-6000g2b-IWL6000G2_UCODE_API_MAX.ucode
          firmware:       iwlwifi-6000g2a-IWL6000G2_UCODE_API_MAX.ucode
          firmware:       iwlwifi-6050-IWL6050_UCODE_API_MAX.ucode
          firmware:       iwlwifi-6000-IWL6000_UCODE_API_MAX.ucode
          firmware:       iwlwifi-100-IWL100_UCODE_API_MAX.ucode
          firmware:       iwlwifi-1000-IWL1000_UCODE_API_MAX.ucode
          firmware:       iwlwifi-105-IWL105_UCODE_API_MAX.ucode
          firmware:       iwlwifi-2030-IWL2030_UCODE_API_MAX.ucode
          firmware:       iwlwifi-2000-IWL2000_UCODE_API_MAX.ucode
      which is obviously wrong, the user should not see the *_UCODE_API_MAX
      macros but the actual ucode API versions here.
      The problem are the
          #define *_MODULE_FIRMWARE(api) *_FW_PRE #api ".ucode"
      which do not expand api correctly (because this is a macro itself).
      Fixed by using __stringify() from linux/stringify.h.
      Further information about macro stringification can be found here:
      Signed-off-by: default avatarEvgeni Golov <sargentd@die-welt.net>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  8. 18 Jun, 2011 3 commits
  9. 03 Jun, 2011 1 commit
    • Stanislaw Gruszka's avatar
      iwlagn: fix channel switch locking · 6f213ff1
      Stanislaw Gruszka authored
      We use priv->mutex to avoid race conditions between iwl_chswitch_done()
      and iwlagn_mac_channel_switch(), when marking channel switch in
      progress. But iwl_chswitch_done() can be called in atomic context
      from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().
      These bugs were introduced by:
      commit 79d07325
      Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
      Date:   Thu May 6 08:54:11 2010 -0700
          iwlwifi: support channel switch offload in driver
      To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
      marking channel switch pending.
      Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
      2.4GHz only devices.
      Cc: stable@kernel.org # 2.6.36+
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 01 Jun, 2011 1 commit
  11. 31 May, 2011 1 commit
  12. 13 May, 2011 2 commits
  13. 06 May, 2011 1 commit
  14. 30 Apr, 2011 3 commits
  15. 18 Apr, 2011 4 commits
  16. 08 Apr, 2011 1 commit
    • 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>