1. 10 3月, 2010 2 次提交
    • J
      iwlwifi: clean up queue/fifo handling · edc1a3a0
      Johannes Berg 提交于
      4965 hardware has 7 queues reserved and the
      remaining ones used for aggregation, 5000
      and higher need to have 10 reserved. This
      is not very clear in the code right now,
      unfortunately.
      
      Introduce a new IWL_TX_FIFO_UNUSED constant
      and make the queue/FIFO mapping arrays able
      to hold that value, and change the setup
      code to reserve all queues in the arrays
      (the queue number is the index) and use the
      new unused constant to not map those queues
      to any FIFO.
      
      Additionally, clear up the AC/queue mapping
      code to be more understandable. The mapping
      is the identity mapping right now, but with
      the mapping function I think it's easier to
      understand what happens there.
      
      Finally, HCCA isn't implemented at all and
      I think newer microcode removed it, so let's
      remove all mention of it in the code, some
      comments remain for 4965.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Acked-by: NShanyu Zhao <shanyu.zhao@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      edc1a3a0
    • J
      iwlwifi: remove frame dropping · 254aebf3
      Johannes Berg 提交于
      With some of the new code in mac80211, public action
      frames can be exchanged as non-injected frames even
      while not associated.
      
      Aside from that, dropping frames here is pointless
      since we do deal with arbitrary frames that were
      injected already, so let mac80211 make the decision
      about which frames to allow or not.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      254aebf3
  2. 24 2月, 2010 1 次提交
  3. 23 2月, 2010 2 次提交
  4. 20 2月, 2010 1 次提交
  5. 12 2月, 2010 3 次提交
  6. 20 1月, 2010 1 次提交
  7. 22 12月, 2009 1 次提交
  8. 08 12月, 2009 1 次提交
  9. 01 12月, 2009 1 次提交
    • J
      mac80211: fix spurious delBA handling · 827d42c9
      Johannes Berg 提交于
      Lennert Buytenhek noticed that delBA handling in mac80211
      was broken and has remotely triggerable problems, some of
      which are due to some code shuffling I did that ended up
      changing the order in which things were done -- this was
      
        commit d75636ef
        Author: Johannes Berg <johannes@sipsolutions.net>
        Date:   Tue Feb 10 21:25:53 2009 +0100
      
          mac80211: RX aggregation: clean up stop session
      
      and other parts were already present in the original
      
        commit d92684e6
        Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
        Date:   Mon Jan 28 14:07:22 2008 +0200
      
            mac80211: A-MPDU Tx add delBA from recipient support
      
      The first problem is that I moved a BUG_ON before various
      checks -- thereby making it possible to hit. As the comment
      indicates, the BUG_ON can be removed since the ampdu_action
      callback must already exist when the state is != IDLE.
      
      The second problem isn't easily exploitable but there's a
      race condition due to unconditionally setting the state to
      OPERATIONAL when a delBA frame is received, even when no
      aggregation session was ever initiated. All the drivers
      accept stopping the session even then, but that opens a
      race window where crashes could happen before the driver
      accepts it. Right now, a WARN_ON may happen with non-HT
      drivers, while the race opens only for HT drivers.
      
      For this case, there are two things necessary to fix it:
       1) don't process spurious delBA frames, and be more careful
          about the session state; don't drop the lock
      
       2) HT drivers need to be prepared to handle a session stop
          even before the session was really started -- this is
          true for all drivers (that support aggregation) but
          iwlwifi which can be fixed easily. The other HT drivers
          (ath9k and ar9170) are behaving properly already.
      Reported-by: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      827d42c9
  10. 24 11月, 2009 1 次提交
  11. 19 11月, 2009 2 次提交
    • J
      mac80211: convert aggregation to operate on vifs/stas · c951ad35
      Johannes Berg 提交于
      The entire aggregation code currently operates on the
      hw pointer and station addresses, but that needs to
      change to make stations purely per-vif; As one step
      preparing for that make the aggregation code callable
      with the station, or by the combination of virtual
      interface and station address.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c951ad35
    • J
      iwlwifi: handle unicast PS buffering · 6ab10ff8
      Johannes Berg 提交于
      Using the new mac80211 functionality, this makes
      iwlwifi handle unicast PS buffering correctly.
      The device works like this:
      
       * when a station goes to sleep, the microcode notices
         this and marks the station as asleep
       * when the station is marked asleep, the microcode
         refuses to transmit to the station and rejects all
         frames queued to it with the failure status code
         TX_STATUS_FAIL_DEST_PS (a previous patch handled
         this correctly)
       * when we need to send frames to the station _although_
         it is asleep, we need to tell the ucode how many,
         and this is asynchronous with sending so we cannot
         just send the frames, we need to wait for all other
         frames to be flushed, and then update the counter
         before sending out the poll response frames. This
         is handled partially in the driver and partially in
         mac80211.
      
      In order to do all this correctly, we need to
       * keep track of how many frames are pending for each
         associated client station (avoid doing it for other
         stations to avoid the atomic ops)
       * tell mac80211 that we driver-block the PS status
         while there are still frames pending on the queues,
         and once they are all rejected (due to the dest sta
         being in PS) unblock mac80211
      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>
      6ab10ff8
  12. 12 11月, 2009 2 次提交
  13. 03 11月, 2009 2 次提交
  14. 28 10月, 2009 4 次提交
  15. 12 10月, 2009 1 次提交
  16. 08 10月, 2009 3 次提交
    • J
      iwlwifi: device tracing · be1a71a1
      Johannes Berg 提交于
      In order to have an easier way to debug issues, create
      trace events (using the ftrace framework) that will
      allow us to follow exactly what the driver is doing
      with the device.
      
      The text format isn't all that useful, but the binary
      format can also be obtained easily via debugfs and
      then analysed on the fly or offline with debugging
      tools.
      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>
      be1a71a1
    • W
      iwlwifi: reliable entering of critical temperature state · 7812b167
      Wey-Yi Guy 提交于
      When uCode detects critical temperature it should send "card state
      notification" interrupt to driver and then shut itself down to prevent
      overheating. There is a race condition where uCode shuts down before it
      can deliver the interrupt to driver.
      Additional method provided here for driver to enter CT_KILL state based
      on temperature reading.
      
      How it works:
      Method 1:
      If driver receive "card state notification" interrupt from uCode; it
      enters "CT_KILL" state immediately
      
      Method 2:
      If the last temperature report by Card reach Critical temperature,
      driver will send "statistic notification" request to uCode to verify the
      temperature reading, if driver can not get reply from uCode within
      300ms, driver will enter CT_KILL state automatically.
      
      Method 3:
      If the last temperature report by Card did not reach Critical
      temperature, but uCode already shut down due to critical temperature.
      All the host commands send to uCode will not get process by uCode;
      when command queue reach the limit, driver will check the last reported
      temperature reading, if it is within pre-defined margin, enter "CT_KILL"
      state immediately. In this case, when uCode ready to exit from "CT_KILL" state,
      driver need to restart the adapter in order to reset all the queues and
      resume normal operation.
      
      One additional issue being address here, when system is in CT_KILL
      state, both tx and rx already stopped, but driver still can send host
      command to uCode, it will flood the command queue since card was not
      responding; adding STATUS_CT_KILL flag to reject enqueue host commands
      to uCode if it is in CT_KILL state, when uCode is ready to come out of
      CT_KILL, driver will clear  the STATUS_CT_KILL bit and allow enqueue the host
      commands to uCode to recover from CT_KILL state.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7812b167
    • D
      iwlwifi: do not clear TX info flags when receiving BlockAckResponse · 91a55ae6
      Daniel C Halperin 提交于
      OR-in AMPDU flags rather than assigning them.  This lets the TX status for
      aggregated packets be processed by rs_tx_status.
      Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      91a55ae6
  17. 29 9月, 2009 1 次提交
  18. 01 9月, 2009 1 次提交
    • D
      iwlwifi: remove incorrect uses of ieee80211_get_tx_rate to prevent TX stall · b58ef214
      Daniel C Halperin 提交于
      Refactor and correct rate selection for outgoing transmitted
      packets.
      
      First, note that HT rates in the mac80211 rate table do not provide valid
      indices when ieee80211_get_tx_rate is called; the check to see if we could to
      abort a transmission early in iwl_tx_skb() would thus occasionally read invalid
      memory and occasionally stall transmission (if the erroneous byte was 0xff).
      We remove that code; the check wasn't valid anyway.
      
      Second, iwl_tx_cmd_build_rate() also called ieee80211_get_tx_rate to be used
      for sending management packets, which do not use the uCode station table.  This
      patch refactors that function and adds comments to enhance legibility, replaces
      the call to ieee80211_get_tx_rate() with a direct lookup, and adds error
      handling in case the table entry is invalid.
      Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b58ef214
  19. 29 8月, 2009 1 次提交
    • G
      iwlwifi: Make injection of non-broadcast frames work again · aa065263
      Gábor Stefanik 提交于
      Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
      ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
      broke injection of non-broadcast frames to unassociated stations
      (causing a SYSASSERT for all such injected frames), due to injected
      frames no longer automatically getting a broadcast station ID assigned.
      This patch restores the old behavior, fixing the aforementioned
      regression.
      
      Also, consistently check for IEEE80211_TX_CTL_INJECTED instead of
      iwl_is_monitor_mode in the TX path, as TX_CTL_INJECTED specifically
      means that a given packet is coming from a monitor interface, while
      iwl_is_monitor_mode only shows whether a monitor interface exists
      on the device.
      Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com>
      Acked-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aa065263
  20. 20 8月, 2009 1 次提交
  21. 14 8月, 2009 3 次提交
  22. 05 8月, 2009 1 次提交
  23. 28 7月, 2009 4 次提交