1. 06 1月, 2010 1 次提交
  2. 29 12月, 2009 1 次提交
  3. 23 12月, 2009 1 次提交
  4. 22 12月, 2009 2 次提交
  5. 05 12月, 2009 1 次提交
  6. 24 11月, 2009 5 次提交
  7. 19 11月, 2009 1 次提交
  8. 12 11月, 2009 1 次提交
  9. 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
  10. 03 11月, 2009 3 次提交
  11. 28 10月, 2009 9 次提交
  12. 08 10月, 2009 9 次提交
  13. 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
  14. 23 9月, 2009 1 次提交
  15. 15 9月, 2009 1 次提交
  16. 01 9月, 2009 1 次提交
  17. 20 8月, 2009 1 次提交
    • J
      mac80211: allow configure_filter callback to sleep · 3ac64bee
      Johannes Berg 提交于
      Over time, a whole bunch of drivers have come up
      with their own scheme to delay the configure_filter
      operation to a workqueue. To be able to simplify
      things, allow configure_filter to sleep, and add
      a new prepare_multicast callback that drivers that
      need the multicast address list implement. This new
      callback must be atomic, but most drivers either
      don't care or just calculate a hash which can be
      done atomically and then uploaded to the hardware
      non-atomically.
      
      A cursory look suggests that at76c50x-usb, ar9170,
      mwl8k (which is actually very broken now), rt2x00,
      wl1251, wl1271 and zd1211 should make use of this
      new capability.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ac64bee