1. 16 1月, 2018 1 次提交
    • R
      ath9k: add MSI support · 7368160f
      Russell Hu 提交于
      On new Intel platforms like ApolloLake, legacy interrupt mechanism
      (INTx) is not supported, so WLAN modules are not working because
      interrupts are missing, therefore this patch is to add MSI support to
      ath9k.  With module paremeter "use_msi=1", ath9k driver would try to
      use MSI instead of INTx.
      Signed-off-by: NRussell Hu <rhu@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7368160f
  2. 14 6月, 2016 1 次提交
    • M
      ath9k: fix GPIO mask for AR9462 and AR9565 · e024111f
      Miaoqing Pan 提交于
      The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
      Also fix the mask for AR9565.
      
      WARNING: CPU: 1 PID: 199 at ../drivers/net/wireless/ath/ath9k/hw.c:2778 ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
      CPU: 1 PID: 199 Comm: kworker/u16:9 Not tainted 4.7.0-rc1-next-20160530+ #5
      Hardware name: Acer TravelMate P243/BA40_HC, BIOS V1.01 04/20/2012
      Workqueue: events_power_efficient rfkill_poll
       0000000000000000 ffff88002cf73d28 ffffffff813b8ddc 0000000000000000
       0000000000000000 ffff88002cf73d68 ffffffff8107a331 00000ada00000086
       ffff880148d9c018 000000000000000b ffff880147e68720 0000000000000200
      Call Trace:
       [<ffffffff813b8ddc>] dump_stack+0x63/0x87
       [<ffffffff8107a331>] __warn+0xd1/0xf0
       [<ffffffff8107a41d>] warn_slowpath_null+0x1d/0x20
       [<ffffffffc0775b19>] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
       [<ffffffffc047f3e4>] ath9k_rfkill_poll_state+0x34/0x60 [ath9k]
       [<ffffffffc06dbb53>] ieee80211_rfkill_poll+0x33/0x40 [mac80211]
       [<ffffffffc03ad65a>] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211]
       [<ffffffff817c5514>] rfkill_poll+0x24/0x50
       [<ffffffff81093183>] process_one_work+0x153/0x3f0
       [<ffffffff8109393b>] worker_thread+0x12b/0x4b0
       [<ffffffff81093810>] ? rescuer_thread+0x340/0x340
       [<ffffffff81099129>] kthread+0xc9/0xe0
       [<ffffffff817d8f1f>] ret_from_fork+0x1f/0x40
       [<ffffffff81099060>] ? kthread_park+0x60/0x60
      
      Fixes: a01ab81b ("ath9k: define correct GPIO numbers and bits mask")
      Reported-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Tested-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e024111f
  3. 11 3月, 2016 3 次提交
  4. 26 1月, 2016 1 次提交
    • M
      ath9k: fix data bus error on ar9300 and ar9580 · 466b0f02
      Miaoqing Pan 提交于
      One crash issue be found on ar9300: RTC_RC reg read leads crash, leading
      the data bus error, due to RTC_RC reg write not happen properly.
      
      Warm Reset trigger in continuous beacon stuck for one of the customer for
      other chip, noticed the MAC was stuck in RTC reset. After analysis noticed
      DMA did not complete when RTC was put in reset.
      
      So, before resetting the MAC need to make sure there are no pending DMA
      transactions because this reset does not reset all parts of the chip.
      
      The 12th and 11th bit of MAC _DMA_CFG register used to do that.
      	12 cfg_halt_ack 0x0
      		0 DMA has not yet halted
      		1 DMA has halted
      	11 cfg_halt_req 0x0
      		0 DMA logic operates normally
      		1 Request DMA logic to stop so software can reset the MAC
      
      The Bit [12] of this register indicates when the halt has taken effect or
      not. the DMA halt IS NOT recoverable; once software sets bit [11] to
      request a DMA halt, software must wait for bit [12] to be set and reset
      the MAC.
      
      So, the same thing we implemented for ar9580 chip.
      Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      466b0f02
  5. 08 4月, 2015 1 次提交
  6. 03 3月, 2015 1 次提交
  7. 06 2月, 2015 1 次提交
  8. 03 2月, 2015 1 次提交
  9. 29 1月, 2015 1 次提交
  10. 15 1月, 2015 1 次提交
  11. 26 11月, 2014 1 次提交
  12. 18 11月, 2014 1 次提交
  13. 28 10月, 2014 1 次提交
  14. 01 10月, 2014 2 次提交
  15. 26 6月, 2014 1 次提交
  16. 20 5月, 2014 1 次提交
    • R
      ath9k_hw: Abort transmission for sleeping station · 08232bf9
      Rajkumar Manoharan 提交于
      The data transmission to the power save station should be aborted
      immediately, whenever the station informs sleep state. Right now
      the frames queued into into hardware are being transmitted until
      the hardware detects the power save station based excessive retries
      of the data frames due to unacknowlegdement. Then remaining frames
      are returned with filetered status and might be retried later by
      driver or mac80211.
      
      Per WFA certification testing, AP should not send out more than two
      frames after processing nullfunc with PM bit set from associated
      station. To speed up tx filtering, the pending frames in hardware
      queues for given station will be aborted immediately via tx filter
      registers. This transmit filters can be ignored if the descriptor
      is having invalid destination index or clear destination mask set.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      08232bf9
  17. 04 1月, 2014 2 次提交
  18. 10 12月, 2013 1 次提交
  19. 03 12月, 2013 1 次提交
  20. 23 8月, 2013 1 次提交
  21. 25 6月, 2013 1 次提交
  22. 25 5月, 2013 2 次提交
  23. 23 4月, 2013 1 次提交
  24. 12 1月, 2013 1 次提交
  25. 08 1月, 2013 1 次提交
  26. 30 10月, 2012 4 次提交
  27. 12 9月, 2012 1 次提交
  28. 13 7月, 2012 1 次提交
  29. 11 7月, 2012 1 次提交
  30. 10 7月, 2012 2 次提交
  31. 21 6月, 2012 1 次提交