1. 23 11月, 2016 7 次提交
    • M
      ath9k: fix NULL pointer dereference · 40bea976
      Miaoqing Pan 提交于
      relay_open() may return NULL, check the return value to avoid the crash.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
      IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
      PGD 41cf28067 PUD 41be92067 PMD 0
      Oops: 0000 [#1] SMP
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
      Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15    07/04/2011
      task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
      RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
      RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
      RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
      Stack:
      0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
      000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
      0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60
      
      Call Trace:
      <IRQ>
      [<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
      [<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
      [<ffffffff8105dde2>] __do_softirq+0x92/0x2a0
      Reported-by: NDevin Tuchsen <devin.tuchsen@gmail.com>
      Tested-by: NDevin Tuchsen <devin.tuchsen@gmail.com>
      Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      40bea976
    • M
      ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success · 91851cc7
      Matthias Schiffer 提交于
      Commit b2d70d49 ("ath9k: make GPIO API to support both of WMAC and
      SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
      changing the return on success from 1 to BIT(gpio). This broke some callers
      like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the
      moment, but should be fixed anyway.
      
      Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
      return 0 or 1.
      
      Fixes: b2d70d49 ("ath9k: make GPIO API to support both of WMAC and SOC")
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: NMatthias Schiffer <mschiffer@universe-factory.net>
      [kvalo@qca.qualcomm.com: mention that doesn't fix any known bug]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      91851cc7
    • M
      ath10k: add spectral scan support to wmi-tlv · 5a401f36
      Michal Kazior 提交于
      Command structure and event flow doesn't seem to
      be any different compared to existing
      implementation for other firmware branches.
      
      This patch effectively adds in-driver support for
      spectral scanning on QCA61x4 and QCA9377.
      
      Tested QCA9377 w/ WLAN.TF.1.0-00267-1.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5a401f36
    • M
      ath10k: fix null deref on wmi-tlv when trying spectral scan · 18ae68ff
      Michal Kazior 提交于
      WMI ops wrappers did not properly check for null
      function pointers for spectral scan. This caused
      null dereference crash with WMI-TLV based firmware
      which doesn't implement spectral scan.
      
      The crash could be triggered with:
      
        ip link set dev wlan0 up
        echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      
      The crash looked like this:
      
        [  168.031989] BUG: unable to handle kernel NULL pointer dereference at           (null)
        [  168.037406] IP: [<          (null)>]           (null)
        [  168.040395] PGD cdd4067 PUD fa0f067 PMD 0
        [  168.043303] Oops: 0010 [#1] SMP
        [  168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 cfg80211 [last unloaded: cfg80211]
        [  168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: G        W  O    4.8.0 #78
        [  168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
        [  168.059183] task: ffff88000c460c00 task.stack: ffff88000d4bc000
        [  168.061736] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
        ...
        [  168.100620] Call Trace:
        [  168.101910]  [<ffffffffa03b9566>] ? ath10k_spectral_scan_config+0x96/0x200 [ath10k_core]
        [  168.104871]  [<ffffffff811386e2>] ? filemap_fault+0xb2/0x4a0
        [  168.106696]  [<ffffffffa03b97e6>] write_file_spec_scan_ctl+0x116/0x280 [ath10k_core]
        [  168.109618]  [<ffffffff812da3a1>] full_proxy_write+0x51/0x80
        [  168.111443]  [<ffffffff811957b8>] __vfs_write+0x28/0x120
        [  168.113090]  [<ffffffff812f1a2d>] ? security_file_permission+0x3d/0xc0
        [  168.114932]  [<ffffffff8109b912>] ? percpu_down_read+0x12/0x60
        [  168.116680]  [<ffffffff811965f8>] vfs_write+0xb8/0x1a0
        [  168.118293]  [<ffffffff81197966>] SyS_write+0x46/0xa0
        [  168.119912]  [<ffffffff818f2972>] entry_SYSCALL_64_fastpath+0x1a/0xa4
        [  168.121737] Code:  Bad RIP value.
        [  168.123318] RIP  [<          (null)>]           (null)
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      18ae68ff
    • P
      ath10k: remove set/get_tsf ieee80211_ops · f6f64cfb
      Pedersen, Thomas 提交于
      Neither of these did the right thing:
      
      - get_tsf just returned 0
      - set_tsf assumed a simple offset was applied against
        get_tsf(), which works, except in the case of
        calculating TSF from rx_mactime (actual TSF).
      
      Just remove them for now. We can reimplement set_tsf in
      terms of TSF increment/decrement in the future if get_tsf
      is ever supported by FW.
      Signed-off-by: NThomas Pedersen <twp@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      f6f64cfb
    • P
      ath10k: implement offset_tsf ieee80211_op · 973324ff
      Pedersen, Thomas 提交于
      Current set_tsf is implemented in terms of TSF_INCREMENT
      only. Instead support new WMI command TSF_DECREMENT and
      export these through offset_tsf. Advantage is we get
      more accurate TSF adjustments, and don't calculate wrong
      offset in case absolute TSF was calculated from rx_mactime
      (actual TSF).
      
      The new WMI command is available in firmware
      10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
      firmware or vice versa shouldn't  be a problem since
      get/set tsf logic was already broken.
      Signed-off-by: NThomas Pedersen <twp@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      973324ff
    • R
      ath10k: advertize hardware packet loss mechanism · ff32eeb8
      Rajkumar Manoharan 提交于
      Indicate hardware (or firmware) supports that CQM packet-loss report
      will be generated based on station kickout algorithm. As of now mac80211
      tracks connection loss by missing msdu counts (50) whereas ath10k
      firmware tracks them by missing ppdus (+ BAR tries). While firmware is
      trying to adapt its rate table, mac80211 might send out low_ack event to
      hostapd. This is causing frequent connect and disconnect iteration under
      noisy environment or when station is roaming around.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ff32eeb8
  2. 17 11月, 2016 1 次提交
    • A
      wireless: fix bogus maybe-uninitialized warning · 10f3366b
      Arnd Bergmann 提交于
      The hostap_80211_rx() function is supposed to set up the mac addresses
      for four possible cases, based on two bits of input data. For
      some reason, gcc decides that it's possible that none of the these
      four cases apply and the addresses remain uninitialized:
      
      drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function ‘hostap_80211_rx’:
      arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’:
      arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&dst+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This warning is clearly nonsense, but changing the last case into
      'default' makes it obvious to the compiler too, which avoids the
      warning and probably leads to better object code too.
      
      The same code is duplicated several times in the kernel, so this
      patch uses the same workaround for all copies. The exact configuration
      was hit only very rarely in randconfig builds and I only saw it
      in three drivers, but I assume that all of them are potentially
      affected, and it's better to keep the code consistent.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      10f3366b
  3. 15 11月, 2016 9 次提交
  4. 21 10月, 2016 1 次提交
    • J
      net: use core MTU range checking in wireless drivers · 9c22b4a3
      Jarod Wilson 提交于
      - set max_mtu in wil6210 driver
      - set max_mtu in atmel driver
      - set min/max_mtu in cisco airo driver, remove airo_change_mtu
      - set min/max_mtu in ipw2100/ipw2200 drivers, remove libipw_change_mtu
      - set min/max_mtu in p80211netdev, remove wlan_change_mtu
      - set min/max_mtu in net/mac80211/iface.c and remove ieee80211_change_mtu
      - set min/max_mtu in wimax/i2400m and remove i2400m_change_mtu
      - set min/max_mtu in intersil/hostap and remove prism2_change_mtu
      - set min/max_mtu in intersil/orinoco
      - set min/max_mtu in tty/n_gsm and remove gsm_change_mtu
      
      CC: netdev@vger.kernel.org
      CC: linux-wireless@vger.kernel.org
      CC: Maya Erez <qca_merez@qca.qualcomm.com>
      CC: Simon Kelley <simon@thekelleys.org.uk>
      CC: Stanislav Yakovlev <stas.yakovlev@gmail.com>
      CC: Johannes Berg <johannes@sipsolutions.net>
      CC: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c22b4a3
  5. 13 10月, 2016 3 次提交
    • M
      ath9k: change entropy formula for easier understanding · e463139a
      Miaoqing Pan 提交于
      The quality of ADC entropy is 10 bits of min-entropy for
      a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
      '(((x) * 8 * 10) >> 5)' for easier understanding.
      Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e463139a
    • V
      ath10k: fix kernel panic due to race in accessing arvif list · ebaa4b16
      Vasanthakumar Thiagarajan 提交于
      arvifs list is traversed within data_lock spin_lock in tasklet
      context to fill channel information from the corresponding vif.
      This means any access to arvifs list for add/del operations
      should also be protected with the same spin_lock to avoid the
      race. Fix this by performing list add/del on arvfis within the
      data_lock. This could fix kernel panic something like the below.
      
       LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core]
       PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core]
       Internal error: Oops: 17 [#1] PREEMPT SMP ARM
       [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core])
       [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core])
       [<c00312d4>] (tasklet_action+0x8c/0xec)
       [<c00309a8>] (__do_softirq+0xdc/0x208)
       [<c0030d6c>] (irq_exit+0x84/0xe0)
       [<c005db04>] (__handle_domain_irq+0x80/0xa0)
       [<c00085c4>] (gic_handle_irq+0x38/0x5c)
       [<c0009640>] (__irq_svc+0x40/0x74)
      
      (gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0)
      0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769)
      764		struct cfg80211_chan_def def;
      765
      766		lockdep_assert_held(&ar->data_lock);
      767
      768		list_for_each_entry(arvif, &ar->arvifs, list) {
      769			if (arvif->vdev_id == vdev_id &&
      770			    ath10k_mac_vif_chan(arvif->vif, &def) == 0)
      771				return def.chan;
      772		}
      773
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ebaa4b16
    • M
      ath10k: cleanup calling ath10k_htt_rx_h_unchain · 7543d116
      Mohammed Shafi Shajakhan 提交于
      'ath10k_htt_rx_h_unchain' needs to be called only if the return
      value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
      change makes it more explicit and avoids doing a skb_peek, fetching
      rx descriptor pointer, checking rx msdu decap format for the case of
      ret = 0 (unchained msdus). Found this change during code walk through,
      not sure if this addresses any issue.
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7543d116
  6. 06 10月, 2016 3 次提交
  7. 04 10月, 2016 5 次提交
  8. 28 9月, 2016 5 次提交
  9. 27 9月, 2016 6 次提交