1. 30 Jun, 2016 2 commits
    • 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 14 commits