1. 08 4月, 2011 2 次提交
  2. 25 3月, 2011 1 次提交
  3. 01 3月, 2011 1 次提交
  4. 22 2月, 2011 1 次提交
  5. 14 12月, 2010 2 次提交
  6. 07 12月, 2010 1 次提交
  7. 25 11月, 2010 1 次提交
  8. 16 11月, 2010 5 次提交
  9. 08 10月, 2010 4 次提交
  10. 06 10月, 2010 1 次提交
    • W
      iwlagn: reduce redundant parameter definitions · 7cb1b088
      Wey-Yi Guy 提交于
      move paramater definitions to a device paramater structure only
      leaving the device name, which antennas are used and what firmware
      file to use in the iwl_cfg structure.  this will not completely
      remove the redundancies but greatly reduce them for devices that
      only vary by name or antennas.  the parameters that are more
      likely to change within a given device family are left in iwl_cfg.
      also separate bt param structure added to help reduce more.
      Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      7cb1b088
  11. 18 9月, 2010 2 次提交
  12. 28 8月, 2010 1 次提交
  13. 27 8月, 2010 2 次提交
  14. 25 8月, 2010 2 次提交
  15. 19 8月, 2010 1 次提交
  16. 14 8月, 2010 2 次提交
    • W
      iwlwifi: use long monitor timer to avoid un-necessary reload · 3198c68c
      Wey-Yi Guy 提交于
      For 5000 and 6000g2b series of devices, use long monitor timer to check
      stuck tx queues.
      
      .6000g2b series device, it is WiFi/BT combo device, there are some cases,
      tx queues are not move for a period of time because the WiFi/BT coex.
      
      .5000 series device, it is being reported firmware got reload more
      often than necessary, so extend the timer to avoid un-necessary reload.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      3198c68c
    • W
      iwlwifi: long monitor timer · ce60659a
      Wey-Yi Guy 提交于
      Change the name for monitor timer, also adding define for long monitor
      timer; long monitor timer can be used for the type of devices require longer
      time to determine the uCode is stuck on tx and needed reload.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      ce60659a
  17. 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
  18. 23 7月, 2010 2 次提交
  19. 03 7月, 2010 3 次提交
  20. 26 6月, 2010 2 次提交
  21. 22 6月, 2010 1 次提交
  22. 06 6月, 2010 2 次提交