1. 03 7月, 2010 1 次提交
    • W
      iwlwifi: fix fw_restart module parameter · c04f9f22
      Wey-Yi Guy 提交于
      fw_restart module parameter was broken by the recent check for stuck
      queue patch, driver check the fx_restart module parameter
      before reload the firmware; but the stuck queue timer kick in after
      firmware error and reload the firmware even fw_restart=0. In this case,
      driver should not reload the firmware, it is important to help debugging
      uCode error.
      
      The only case we can ignore the module parameter is when user request
      firmware reload from debugfs, which can bypass the checking and perform
      firmware reload all the time.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      c04f9f22
  2. 26 6月, 2010 2 次提交
  3. 22 6月, 2010 2 次提交
  4. 06 6月, 2010 5 次提交
  5. 14 5月, 2010 2 次提交
  6. 11 5月, 2010 12 次提交
  7. 28 4月, 2010 1 次提交
  8. 17 4月, 2010 6 次提交
  9. 10 4月, 2010 1 次提交
  10. 03 4月, 2010 1 次提交
  11. 01 4月, 2010 1 次提交
    • S
      iwlwifi: manage QoS by mac stack · e61146e3
      Stanislaw Gruszka 提交于
      We activate/deactivate QoS and setup default queue parameters in iwlwifi
      driver. Mac stack do the same, so we do not need repeat that work here.
      Stack also will tell when disable QoS, this will fix driver when working
      with older APs, that do not have QoS implemented.
      
      Patch make "force = true" in iwl_active_qos() assuming we always want
      to do with QoS what mac stack wish.
      
      Patch also remove unused qos_cap bits, do not initialize qos_active = 0,
      as we have it initialized to zero by kzalloc.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e61146e3
  12. 26 3月, 2010 5 次提交
  13. 20 3月, 2010 1 次提交
    • W
      iwlwifi: code cleanup for connectivity recovery · fa8f130c
      Wey-Yi Guy 提交于
      Split the connectivity check and recovery routine into separated
      functions based on the types
         1. iwl_good_ack_health() - check for ack count
         2. iwl_good_plcp_health() - check for plcp error
      
      Based on the type of errors being detected, different recovery methods
      will be used to bring the system back to normal operational state.
      
      Because different NIC has different HW and uCode, the behavior is also
      different; these functions thus now form part of the ops infrastructure,
      so we can have more control on how to monitor and recover from error condition
      case per device.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      fa8f130c