1. 28 8月, 2010 5 次提交
  2. 27 8月, 2010 3 次提交
  3. 26 8月, 2010 7 次提交
  4. 25 8月, 2010 7 次提交
  5. 18 8月, 2010 1 次提交
  6. 17 8月, 2010 3 次提交
  7. 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
  8. 05 8月, 2010 1 次提交
  9. 28 7月, 2010 1 次提交
  10. 23 7月, 2010 1 次提交
  11. 21 7月, 2010 1 次提交
    • J
      mac80211: move QoS-enable to BSS info · 4ced3f74
      Johannes Berg 提交于
      Ever since
      
      commit e1b3ec1a
      Author: Stanislaw Gruszka <sgruszka@redhat.com>
      Date:   Mon Mar 29 12:18:34 2010 +0200
      
          mac80211: explicitly disable/enable QoS
      
      mac80211 is telling drivers, in particular
      iwlwifi, whether QoS is enabled or not.
      
      However, this is only relevant for station mode,
      since only then will any device send nullfunc
      frames and need to know whether they should be
      QoS frames or not. In other modes, there are
      (currently) no frames the device is supposed to
      send.
      
      When you now consider virtual interfaces, it
      becomes apparent that the current mechanism is
      inadequate since it enables/disables QoS on a
      global scale, where for nullfunc frames it has
      to be on a per-interface scale.
      
      Due to the above considerations, we can change
      the way mac80211 advertises the QoS state to
      drivers to only ever advertise it as "off" in
      station mode, and make it a per-BSS setting.
      Tested-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4ced3f74
  12. 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
  13. 26 6月, 2010 3 次提交
  14. 06 6月, 2010 5 次提交