1. 20 3月, 2010 2 次提交
    • R
      iwlwifi: implement new mac80211 station add/remove calls · fe6b23dd
      Reinette Chatre 提交于
      mac80211 recently implemented two new callbacks that are used to request
      station add/remove from the driver. The benefot from these new callbacks
      are that they enable the driver to sleep while performing this work.
      
      This is a big patch since a few things need to be coordinated in this move.
      First we need to decouple station management from rate scaling, which
      caused a lot of code to be moved and/or deleted. Next we needed to tie in
      with mac80211's station management callback and let it direct our station
      management as well as trigger the rate scaling initialization.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      fe6b23dd
    • R
      iwlwifi: only add broadcast station once · 7e246191
      Reinette Chatre 提交于
      Currently the broadcast station is added after every RXON command. Change
      this to only add the broadcast station when interface is added by mac80211.
      With this we need some extra work to ensure broadcast station is always
      present since station table is cleared when RXON without ASSOC bit set is
      sent. To deal with this we re-add all driver known stations to uCode after
      such an RXON command is sent.
      
      We also do some cleanup and remove the various calls to clear the station
      table. We now only clear the station table in two scenarios:
      - only clear uCode portion of station table when RXON command without ASSOC
      bit is sent
      - clear uCode and driver portion when interface goes down or is removed.
      
      We need to do this clearing when interface goes down to deal with the
      device restart/reconfigure routines which do not remove the interface, but
      do add the interface during reconfiguration.
      
      Previously the keys were also cleared when station table in driver is
      cleared, this is not done anymore since mac80211 will take care that keys
      are set and cleared correctly.
      
      There is a known issue with this change. Associating with different AP
      without bringing interface down fails with a firmware error. This is
      because of the lack of full station notification support and the later
      patches in this series that complete the station notification support will
      fix this.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      7e246191
  2. 10 3月, 2010 8 次提交
  3. 03 3月, 2010 1 次提交
    • J
      iwlwifi: load firmware asynchronously before mac80211 registration · b08dfd04
      Johannes Berg 提交于
      At the wireless summit in Portland we discussed a way of
      loading firmware asynchronously from ->probe() before
      registration to mac80211, in order to register with the
      wireless subsystems with complete information in cases
      where firmware is required to know parameters.
      
      This is not yet the case in iwlwifi, but for some new
      features we're working on it will be the case since
      those will only be supported by new firmware images.
      
      Hence, to start with, convert iwlwifi to load firmware
      asynchronously from probe, unbinding the device when
      firmware loading fails, and only registering with the
      wireless subsystems after firmware has been loaded
      successfully.
      
      Future patches will hook into this to register the
      new firmware capabilities, depending on the firmware
      API version.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b08dfd04
  4. 24 2月, 2010 1 次提交
    • R
      Revert "iwlwifi: Monitor and recover the aggregation TX flow failure" · ab9bdc34
      Reinette Chatre 提交于
      This reverts commit 1db5950f.
      
      The goal of "iwlwifi: Monitor and recover the aggregation TX flow failure"
      is to first detect when data transmission stalls and then to recover from
      this situation with a reset of the radio or the firmware, depending on how
      bad the transmission failures are.
      
      Unfortunately we have found that this change causes excessive resets with
      its current detection algorithm. It also performs its recovery action when
      none is really needed, like when we are not associated.
      
      Revert this change until the issues have been addressed.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      ab9bdc34
  5. 20 2月, 2010 2 次提交
  6. 12 2月, 2010 2 次提交
    • T
      iwlwifi: Monitor and recover the aggregation TX flow failure · 1db5950f
      Trieu 'Andrew' Nguyen 提交于
      This change monitors the tx statistics to detect the drop in throughput.
      When the throughput drops, the ratio of the actual_ack_count and the expected_
      ack_count also drops.  At the same time, the aggregated ba_timeout (the number
      of ba timeout retries) also rises.  If the actual_ack_count/expected_ack_count
      ratio is 0 and the number of ba timeout retries rises to 16, no tx packets
      (tcp, udp, or ping - icmp) can be delivered.  The driver recovers from this
      situation by reseting the uCode firmware.  If the actual_ack_count/expected_
      ack_count ratio drops below 50% (but not 0) and the aggregated ba_timeout
      retries just exceed 5 (but not 16), then the driver can reset the radio to
      bring the throughput up.
      Signed-off-by: NTrieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      1db5950f
    • R
      iwlwifi: reset card during probe · 4843b5a7
      Reinette Chatre 提交于
      To ensure that card is in a sane state during probe we add a reset call.
      This change was prompted by users of kdump who was not able to bring up the
      wireless driver in the kdump kernel. The problem here was that the primary
      kernel, which is not running at the time, left the wireless card up and
      running. When the kdump kernel starts it is thus possible to immediately
      receive interrupts from firmware after registering interrupt, but without
      being ready to deal with interrupts from firmware yet.
      Reported-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      4843b5a7
  7. 09 2月, 2010 2 次提交
  8. 30 1月, 2010 3 次提交
  9. 26 1月, 2010 5 次提交
  10. 23 1月, 2010 1 次提交
  11. 20 1月, 2010 2 次提交
  12. 13 1月, 2010 1 次提交
  13. 08 1月, 2010 1 次提交
  14. 23 12月, 2009 1 次提交
  15. 22 12月, 2009 5 次提交
  16. 05 12月, 2009 1 次提交
  17. 24 11月, 2009 2 次提交