1. 25 8月, 2010 1 次提交
  2. 10 8月, 2010 1 次提交
    • J
      iwlagn: fix rts cts protection · 94597ab2
      Johannes Berg 提交于
      Currently the driver will try to protect all frames,
      which leads to a lot of odd things like sending an
      RTS with a zeroed RA before multicast frames, which
      is clearly bogus.
      
      In order to fix all of this, we need to take a step
      back and see what we need to achieve:
       * we need RTS/CTS protection if requested by
         the AP for the BSS, mac80211 tells us this
       * in that case, CTS-to-self should only be
         enabled when mac80211 tells us
       * additionally, as a hardware workaround, on
         some devices we have to protect aggregated
         frames with RTS
      
      To achieve the first two items, set up the RXON
      accordingly and set the protection required flag
      in the transmit command when mac80211 requests
      protection for the frame.
      
      To achieve the last item, set the rate-control
      RTS-requested flag for all stations that we have
      aggregation sessions with, and set the protection
      required flag when sending aggregated frames (on
      those devices where this is required).
      
      Since otherwise bugs can occur, do not allow the
      user to override the RTS-for-aggregation setting
      from sysfs any more.
      
      Finally, also clean up the way all these flags get
      set in the driver and move everything into the
      device-specific functions.
      
      Cc: stable@kernel.org [2.6.35]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      94597ab2
  3. 23 7月, 2010 2 次提交
  4. 10 7月, 2010 1 次提交
  5. 03 7月, 2010 3 次提交
  6. 26 6月, 2010 3 次提交
  7. 06 6月, 2010 3 次提交
  8. 14 5月, 2010 2 次提交
  9. 11 5月, 2010 6 次提交
  10. 01 5月, 2010 2 次提交
  11. 17 4月, 2010 4 次提交
  12. 10 4月, 2010 1 次提交
  13. 26 3月, 2010 10 次提交
  14. 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