1. 26 1月, 2010 1 次提交
    • W
      iwlwifi: add function to reset/tune radio if needed · afbdd69a
      Wey-Yi Guy 提交于
      Adding "radio reset" function to help reset and stabilize the radio.
      
      During normal operation, sometime for unknown reason, radio encounter
      problem and can not recover by itself; the best way to
      recover from it is to reset and re-tune the radio. Currently, there is
      no RF reset command available, but since radio will get reset when
      switching channel, use internal hw scan request to force radio
      reset and get back to normal operation state.
      
      The internal hw scan will only perform passive scan on the first
      available channel (not the channel being used) in associated state. The
      request should be ignored if already performing scan operation or STA is
      not in associated state.
      
      Also include an "internal_scan" debugfs file to help trigger the
      internal scan from user mode.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afbdd69a
  2. 20 1月, 2010 2 次提交
  3. 06 1月, 2010 1 次提交
  4. 29 12月, 2009 1 次提交
  5. 23 12月, 2009 1 次提交
  6. 22 12月, 2009 2 次提交
  7. 05 12月, 2009 1 次提交
  8. 24 11月, 2009 5 次提交
  9. 19 11月, 2009 1 次提交
  10. 12 11月, 2009 1 次提交
  11. 11 11月, 2009 1 次提交
    • W
      iwlwifi: Use RTS/CTS as the preferred protection mechanism for 6000 series · 73871f71
      Wey-Yi Guy 提交于
      When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection
      mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field
      in the HT Information Element to determine whether or not to use
      protection.
      
      The Operating Mode field has 4 possible settings: 0-3:
      Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the
      BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT
      stations in a 20 MHz BSS
      Mode 1: used if there are non-HT stations or APs using the primary or
      secondary channels
      Mode 2: if only HT stations are associated in the BSS and at least one
      20 MHz HT station is associated.
      Mode 3: used if one or more non-HT stations are associated in the BSS.
      
      When in operating modes 1 or 3, and the Use_Protection field is 1 in the
      Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or
      CTS-to-Self.
      
      By default, CTS-to-self is the preferred protection mechanism for less
      overhead and higher throughput; but using the full RTS/CTS will better
      protect the inner exchange from interference, especially in
      highly-congested environment.
      
      For 6000 series WIFI NIC, RTS/CTS protection mechanism is the
      recommended choice for HT traffic based on the HW design.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      73871f71
  12. 03 11月, 2009 3 次提交
  13. 28 10月, 2009 9 次提交
  14. 08 10月, 2009 9 次提交
  15. 29 9月, 2009 1 次提交
    • R
      iwlwifi: fix 3945 ucode info retrieval after failure · b7a79404
      Reinette Chatre 提交于
      When hardware or uCode problem occurs driver captures significant
      information from device to enable debugging. The format of this information
      is different between 3945 and 4965 and later devices, yet currently the
      3945 uses the 4965 and later format. Fix this by adding a new library call
      that is initialized to the correct formatting routine based on device.
      
      This moves the iwlagn event and error log handling back to iwl-agn.c to
      make it part of iwlagn module.
      
      Also remove the 3945 sysfs file that triggers dump of event log - there is
      already a debugfs file that can do it for all drivers.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b7a79404
  16. 23 9月, 2009 1 次提交