1. 30 Jun, 2016 7 commits
    • Eduardo Abinader's avatar
      ath9k: return false when reading wrong eeprom offset · 0f27ac40
      Eduardo Abinader authored
      Just setting the proper return for reading beyond the eeprom data.
      Signed-off-by: default avatarEduardo Abinader <eduardo.abinader@riverbed.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      0f27ac40
    • Mohammed Shafi Shajakhan's avatar
      ath10k: fix some typo in spectral code commments · 3fa35bac
      Mohammed Shafi Shajakhan authored
      Found this obvious typo while going through the spectral
      code design in ath10k
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      3fa35bac
    • Mohammed Shafi Shajakhan's avatar
      ath10k: disable TX_STBC for tx chainmask of 1 · 34663241
      Mohammed Shafi Shajakhan authored
      Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1'
      TX_STBC is required only for devices with tx_chainmask > 1. This fixes
      a ping failure for QCA9887 (1x1) in HT/VHT mode
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      34663241
    • Mohammed Shafi Shajakhan's avatar
      ath10k: enable beacon loss detection support for 10.4 · 343bf960
      Mohammed Shafi Shajakhan authored
      Enable beacon loss detection support for 10.4 by handling
      roam event. With this change QCA99X0 station is able to
      detect beacon loss when the AP is powered off
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      343bf960
    • Bob Copeland's avatar
      ath10k: fix potential null dereference bugs · a66cd733
      Bob Copeland authored
      Smatch warns about a number of cases in ath10k where a pointer is
      null-checked after it has already been dereferenced, in code involving
      ath10k private virtual interface pointers.
      
      Fix these by making the dereference happen later.
      
      Addresses the following smatch warnings:
      
      drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649)
      drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659)
      drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52)
      drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736)
      drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84)
      drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825)
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      a66cd733
    • Mohammed Shafi Shajakhan's avatar
      ath10k: remove unneccessary WARN_ON_ONCE in rx during ACS · 569fba2c
      Mohammed Shafi Shajakhan authored
      The below warning message seems to hit occasionally with the following
      combination (IPQ4019 + ACS scan) where we receive packets as a self peer
      when hostapd does ACS when we bring up AP mode . ath10k has the below
      fall back mechanism to fetch current operating channel in rx (it will
      check for the next channel tracking variable if the current one is NULL)
      
      	[scan channel] --> [rx channel] --> [peer channel] -->
      	[vdev channel] -->  [any vdev channel] --> [target oper channel]
      
      'scan channel' and 'target operating channel' are directly fetched from
      firmware events. All the others should be updated by mac80211.
      
      During ACS scan we wouldn't have a valid channel context
      assigned from mac80211 ('ar->rx_channel'), and also relying on
      ('ar->scan_channel') is not helpful (it becomes NULL when it goes to
      BSS channel and also when the scan event is completed). In short we
      cannot always rely on these two channel tracking variables.
      
      'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
      the current operating even while we are doing ACS scan and etc. Hence
      remove this un-necessary warning message and continue with
      target_operating channel. At the worst case scenario when the target
      operating channel is invalid (NULL) we already have an ath10k warning
      message to notify we really don't have a proper channel configured in
      rx to update the rx status("no channel configured; ignoring frame(s)!")
      
          WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
          [<c0318838>] (warn_slowpath_null) from [<bf4a0104>]
          (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
          [<bf4a0104>] (ath10k_htt_rx_h_channel [ath10k_core]) from
          [<bf4a025c>] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
          [<bf4a025c>] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
          [<bf4a1a9c>] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
          [<bf4a1a9c>] (ath10k_htt_txrx_compl_task [ath10k_core])
      
      Fixes:3b0499e9 ("ath10k: reduce warning messages during rx without proper channel context")
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      569fba2c
    • Mohammed Shafi Shajakhan's avatar
      ath10k: fix crash during card removal · fb7caaba
      Mohammed Shafi Shajakhan authored
      Usually when the firmware crashes we check for the value
      'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with
      disabling the irq and dumping firmware 'crash dump'. Now
      when the PCI card is unplugged from the device the PCI controller
      seems to generate a spurious interrupt after some time which
      was as treated a firmware crash and resulting in the below race
      condition (and eventually crashing the system)
      
      	ath10k_core_unregister -> ath10k_core_free_board_files
      
      	...... device unplug spurious interrupt .........
      
      	ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump  ...etc
      
      Clearly even after the firmware board files related data structure
      is freed up we are getting a spurious interrupt from PCI with 0xfffffff
      in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet
      and doing a crash dump, printing f/w board related info resulting in the
      below crash. Fix this by detecting this spurious interrupt in ath10k PCI
      irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for
      helping us conclude the most appropriate fix.
      
      Call trace:
      
       EIP is at ath10k_debug_print_board_info+0x39/0xb0
      [ath10k_core]
      EAX: 00000000 EBX: d4de15a0 ECX: 00000000 EDX: 00000064
      ESI: f615ddd0 EDI: f8530000 EBP: f615de3c ESP: f615ddbc
       DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      CR0: 80050033 CR2: 00000004 CR3: 01c0a000 CR4: 000006f0
      Stack:
       f615ddd0 00000064 f8b4ecdd 00000000 00000000 00412f4e
      00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000
       00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000
      Call Trace:
        [<f8b1f517>] ath10k_print_driver_info+0x17/0x30
      [ath10k_core]
      [<f875463a>] ath10k_pci_fw_crashed_dump+0x7a/0xe0
      [ath10k_pci]
      [<f87549d0>] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci]
      [<c106151e>] tasklet_action+0x9e/0xb0
      
      Cc: Michal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      fb7caaba
  2. 29 Jun, 2016 24 commits
  3. 28 Jun, 2016 9 commits