1. 23 1月, 2010 1 次提交
  2. 20 1月, 2010 2 次提交
  3. 13 1月, 2010 1 次提交
  4. 23 12月, 2009 1 次提交
  5. 22 12月, 2009 5 次提交
  6. 05 12月, 2009 1 次提交
  7. 24 11月, 2009 6 次提交
  8. 20 11月, 2009 1 次提交
  9. 19 11月, 2009 6 次提交
  10. 12 11月, 2009 7 次提交
  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 7 次提交
  13. 28 10月, 2009 1 次提交
    • B
      iwlwifi: make sure device is reset when unloading driver · c166b25a
      Ben Cahill 提交于
      Add unconditional call to apm_ops.stop() to reset device to low power state
      when unloading driver.  Some paths have existed to unload driver *without*
      resetting device, therefore some errors have persisted through multiple
      load/unload cycles, until the whole platform gets rebooted; this is an
      attempt to remedy some of those situations.  Sorry, I can't seem to find
      a bughost.org bug that specifically has these symptoms, but I had it happen
      recently here.
      
      Note that this will *not* fix situations in which the PCI express bus has
      crashed (evidenced by register reads showing "0xffffffff"), e.g. bughost.org
      1855 and 2096; device is unreachable from driver in those cases.
      Signed-off-by: NBen Cahill <ben.m.cahill@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c166b25a