1. 12 9月, 2012 15 次提交
  2. 08 9月, 2012 3 次提交
    • S
      ath9k: Fix TX filter usage · adfbda62
      Sujith Manoharan 提交于
      The TX filter bit for a station would be set by the HW
      when a frame is not acked. A frame would be completed with
      ATH9K_TXERR_FILT status only when the corresponding filter bit
      for the destination station is already set.
      
      Currently, un-acknowledged  packets are added to the pending queue
      and retried, but the "clear_dest_mask" bit in the descriptor is
      set only when the TX status has been ATH9K_TXERR_FILT. This results
      in packet loss and the log shows:
      
      wlan0: dropped TX filtered frame, queue_len=0 PS=0 @4309746071
      wlan0: dropped TX filtered frame, queue_len=0 PS=0 @4309746076
      wlan0: dropped TX filtered frame, queue_len=0 PS=0 @4309746377
      ...
      ...
      
      This issue can be resolved by making sure that the destination
      mask is cleared when the packet is being retried and the earlier
      TX status is ATH9K_TXERR_XRETRY.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      adfbda62
    • M
      ath9k_hw: small optimization · 4653356f
      Mohammed Shafi Shajakhan 提交于
      Assign the MCI BT state locally, rather than unnecessarily calling
      ar9003_mci_state and updating it.
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4653356f
    • M
      wireless: ath9k-htc: only load firmware in need · 32e31de5
      Ming Lei 提交于
      It is not necessary to hold the firmware memory during the whole
      driver lifetime, and obviously it does waste memory. Suppose there
      are 4 ath9k-htc usb dongles working, kernel has to consume about
      4*50KBytes RAM to cache firmware for all dongles. After applying the
      patch, kernel only caches one single firmware image in RAM for
      all ath9k-htc devices just during system suspend/resume cycle.
      
      When system is ready for loading firmware, ath9k-htc can request
      the loading from usersapce. During system resume, ath9k-htc still
      can load the firmware which was cached in kernel memory before
      system suspend.
      
      Cc: ath9k-devel@lists.ath9k.org
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      32e31de5
  3. 06 9月, 2012 7 次提交
    • M
      ath9k: Fix a crash in 2 WIRE btcoex chipsets · 5d9b6f26
      Mohammed Shafi Shajakhan 提交于
      Generic timers for BTCOEX functionality is applicable
      only for 3 WIRE BTCOEX (and MCI) chipsets.
      Hence btcoex->no_stomp_timer is allocated only 3 WIRE
      btcoex chipsets and in all the other cases its NULL.
      Make sure we stop the generic timer only if
      'btcoex->hw_timer_enabled' is true(only if its up and
      running)
      
      Fixes the following crash
      
      	[68757.020454] BUG: unable to handle kernel NULL pointer dereference at 0000000c
      	[68757.020916] IP: [<f9b055c3>] ath9k_hw_gen_timer_stop+0x13/0x80 [ath9k_hw]
      	[68757.021251] *pde = 00000000
      	[68757.024384] EIP: 0060:[<f9b055c3>] EFLAGS: 00010082 CPU: 0
      	[68757.024384] EIP is at ath9k_hw_gen_timer_stop+0x13/0x80 [ath9k_hw]
      	[68757.024384] EAX: d32d0000 EBX: d32d0000 ECX: 00000000 EDX: 00000000
      	[68757.024384] ESI: e67c24c0 EDI: 00000296 EBP: e137be2c ESP: e137be20
      	[68757.024384]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      	[68757.024384] CR0: 8005003b CR2: 0000000c CR3: 00b99000 CR4: 000407d0
      	[68757.024384] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      	[68757.024384] DR6: ffff0ff0 DR7: 00000400
      	[68757.024384] Process kworker/u:2 (pid: 8917, ti=e137a000 task=ea7a6860 task.ti=e137a000)
      	[68757.024384] Stack:
      	[68757.024384]  c06c4676 d32d0000 e67c24c0 e137be38 f81c9590 e67c1ca0 e137be40 f81c95d9
      	[68757.024384]  e137be64 f81cd1c5 00000246 00000002 d32d0000 e67c05e0 e67c1ca0 e67c05e0
      	[68757.024384]  00000000 e137beac f81cdfa0 e137be84 00000246 00000246 e67c1ca0 e67c1ca0
      	[68757.024384] Call Trace:
      	[68757.024384]  [<c06c4676>] ? _raw_spin_lock_irqsave+0x86/0xa0
      	[68757.024384]  [<f81c9590>] ath9k_gen_timer_stop+0x10/0x40 [ath9k]
      	[68757.024384]  [<f81c95d9>] ath9k_btcoex_stop_gen_timer+0x19/0x20 [ath9k]
      	[68757.024384]  [<f81cd1c5>] ath9k_ps_restore+0x85/0x110 [ath9k]
      	[68757.024384]  [<f81cdfa0>] ath9k_config+0x220/0x520 [ath9k]
      	[68757.024384]  [<f81cd47d>] ? ath9k_flush+0x15d/0x1b0 [ath9k]
      	[68757.024384]  [<f85c7ca5>] ieee80211_hw_config+0x135/0x2c0 [mac80211]
      	[68757.024384]  [<f860e3c8>] ieee80211_dynamic_ps_enable_work+0x198/0x5f0 [mac80211]
      
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Bala Shanmugam <bkamatch@qca.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5d9b6f26
    • F
      ath9k_hw: enable PA linearization · b3ccc1a5
      Felix Fietkau 提交于
      This feature had been disabled in ath9k because the code to support
      it was incomplete, but now the code is in sync with the internal QCA
      codebase, so it's time to enable it.
      
      On many newer devices, the calibration is assumed to be done with PA
      linearization enabled.
      
      Tests with a particular AR933x device showed that the signal emitted
      at full power was highly distorted and unreliable with PA linearization
      disabled. With this patch, the signal becomes clear and stability
      is improved.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b3ccc1a5
    • F
      ath9k: fix PA linearization calibration related crash · 51dea9be
      Felix Fietkau 提交于
      Before PAPRD training can run, the card needs to have sent a packet for
      thermal calibration. Sending a dummy packet with the PAPRD training flag
      set causes a crash under some circumstance.
      Fix the code by replacing the dummy tx with a delay that waits for a
      real packet tx to have occurred.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      51dea9be
    • F
      ath9k_hw: disable PA linearization for AR9462 · 1630d25f
      Felix Fietkau 提交于
      Support for it is incomplete
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1630d25f
    • F
      ath9k_hw: calibrate PA input for PA predistortion · 381c726c
      Felix Fietkau 提交于
      Re-train if the calibrated PA linearization curve is out of bounds
      (affects AR933x and AR9485).
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      381c726c
    • F
      ath9k_hw: clear the AM2PM predistortion mask on AR933x · 26228959
      Felix Fietkau 提交于
      That predistortion type is not supported
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      26228959
    • F
      ath9k_hw: do not enable the MIB interrupt in the interrupt mask register · 280b9a9d
      Felix Fietkau 提交于
      The interrupt is no longer handling it. While it shouldn't fire (wraparound
      is highly unlikely), the consequences would be fatal (interrupt storm).
      Disable the interrupt to prevent that from happening.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      280b9a9d
  4. 22 8月, 2012 1 次提交
  5. 14 8月, 2012 1 次提交
    • L
      ath9k: fix decrypt_error initialization in ath_rx_tasklet() · e1352fde
      Lorenzo Bianconi 提交于
      ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
      in a loop over the received frames. The decrypt_error flag is
      initialized to false
      just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
      ath9k_rx_skb_preprocess(),
      only sets decrypt_error to true and never to false.
      Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
      decrypt_error to it.
      So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
      have a leftover value
      from another processed frame. In that case, the frame will not be marked with
      RX_FLAG_DECRYPTED even if it is decrypted correctly.
      When using CCMP encryption this issue can lead to connection stuck
      because of CCMP
      PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
      deciphered frame with ieee80211_aes_ccm_decrypt.
      Fix the issue initializing decrypt_error flag at the begging of the
      ath_rx_tasklet() loop.
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e1352fde
  6. 11 8月, 2012 13 次提交