With maximum number of vap's configured in a two radio supported
systems of ~256 Mb RAM, doing a continuous wifi down/up and
intermittent traffic streaming from the connected stations results
in failure to allocate contiguous memory for tx buffers. This results
in the disappearance of all VAP's and a manual reboot is needed as
this is not a crash (or) OOM(for OOM killer to be invoked). To address
this allocate contiguous memory for tx buffers one time and re-use them
until the modules are unloaded but this results in a slight increase in
memory footprint of ath10k when the wifi is down, but the modules are
still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
to keep track of the one time memory allocation, as we cannot come up
with something like 'ath10k_tx_{register,unregister}' before
'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
memory allocation is dependent on the hw_param 'continuous_frag_desc'
a) memory footprint of ath10k without the change
lsmod | grep ath10k
ath10k_core 414498 1 ath10k_pci
ath10k_pci 38236 0
b) memory footprint of ath10k with the change
ath10k_core 414980 1 ath10k_pci
ath10k_pci 38236 0
Memory Failure Call trace:
hostapd: page allocation failure: order:6, mode:0xd0
[<c021f150>] (__dma_alloc_buffer.isra.23) from
[<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
[<c021f23c>] (__alloc_remap_buffer.isra.26) from
[<c021f664>] (__dma_alloc+0x224/0x2b8)
[<c021f664>] (__dma_alloc) from [<c021f810>]
(arm_dma_alloc+0x84/0x90)
[<c021f810>] (arm_dma_alloc) from [<bf954764>]
(ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
[<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
[<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
[<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
[<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
[<bf947eec>] (ath10k_start [ath10k_core]) from
[<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
[<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
(ieee80211_do_open+0x170/0x82c [mac80211])
[<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
[<c056afc8>] (__dev_open+0xa0/0xf4)
[21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
0*1024kB 0*2048kB 0*4096kB = 95276kB
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.
During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')
'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
Fixes: 3c97f5de1f ("ath10k: implement NAPI support")
Cc: <stable@vger.kernel.org> # v4.9
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In order to receive other BSS entries in mesh mode, Monitor vdev
is created whenever filter flag is set with OTHER_BSS. Recently
it is root caused that setting promisc filter for Mesh interface
is causing performance and stability issues. To fix this issue,
firmware will configure appropriate rxfilters by default for mesh
vdev during vdev creation. This change fixes monitor vdev creation
based on firmware IE
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.
This is a hack and might cause subtle problems but as it's not enabled by
default (only when user space changes the coverage class explicitly) it should
not cause new problems for existing setups. But still this should be considered
as an experimental feature and used with caution.
This patch implements the support for first generation cards (QCA9880, QCA9887
and so on) which are based on a core that is similar to ath9k. The registers
are modified in place and need to be re-written every time the firmware sets
them. To achieve this the register status is verified after certain WMI events
from the firmware.
The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.
Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
During offchannel scan, iw survey dump shows wrong values.
Fix this by assigning cycle counter wranarround type for
QCA9888 and QCA9884, they share same config with QCA4019.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The (1 << x) - 1 trick won't work when you
are trying to fill up all 64 bits, so add special
case for that.
Signed-off-by: Ben Greear <greearb@candelatech.com>
[kvalo@qca.qualcomm.com: remove the sentence about moving limits]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
rx_hdr_status is not padded to align in 4-byte boundary. Define a
new hw_params field to handle different alignment behaviour between
different hw. This patch fixes improper retrieval of rfc1042 header
with QCA4019. This patch along with "ath10k: Properly remove padding
from the start of rx payload" will fix traffic failure in ethernet
decap mode for QCA4019.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
hw_4addr_pad was added to handle different types of padding
in 4-address rx frame. But this padding is not very specific
to 4-address, it can happen even with three address + ethernet
decap mode. Since the padding information can be obtained
through Rx desc for QCA99X0 and newer chips, this hw_param
is not needed any more.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There are slight differences in Rx hw descriptor information
among different chips. So far driver does not use those new
information for any functionalities, but there is one important
information which is available from QCA99X0 onwards to indicate
the number of bytes that hw padded at the begining of the rx
payload and this information is needed to undecap the rx
packet. Add an abstraction for Rx desc to make use of the
new desc information available. The callback that this patch
defines to retrieve the padding bytes will be used in follow-up
patch.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
IFTYPE_MESH_POINT need to rely on these for accurate path
selection metrics. Other modes will probably also find
them useful. Enabling peer stats has the side effect of
reducing max number of STAs from 128 to 118. There should
be negligible performance impact.
If users really need 128 STAs and don't mind losing out on
peer stats, they can still disable them:
echo 0 > debugfs/ieee80211/phyn/ath10k/peer_stats
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add NAPI support for rx and tx completion. NAPI poll is scheduled
from interrupt handler. The design is as below
- on interrupt
- schedule napi and mask interrupts
- on poll
- process all pipes (no actual Tx/Rx)
- process Rx within budget
- if quota exceeds budget reschedule napi poll by returning budget
- process Tx completions and update budget if necessary
- process Tx fetch indications (pull-push)
- push any other pending Tx (if possible)
- before resched or napi completion replenish htt rx ring buffer
- if work done < budget, complete napi poll and unmask interrupts
This change also get rid of two tasklets (intr_tq and txrx_compl_task).
Measured peak throughput with NAPI on IPQ4019 platform in controlled
environment. No noticeable reduction in throughput is seen and also
observed improvements in CPU usage. Approx. 15% CPU usage got reduced
in UDP uplink case.
DL: AP DUT Tx
UL: AP DUT Rx
IPQ4019 (avg. cpu usage %)
========
TOT +NAPI
=========== =============
TCP DL 644 Mbps (42%) 645 Mbps (36%)
TCP UL 673 Mbps (30%) 675 Mbps (26%)
UDP DL 682 Mbps (49%) 680 Mbps (49%)
UDP UL 720 Mbps (28%) 717 Mbps (11%)
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Older firmware with HTT delivers incorrect tx status for null func
frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
Also this workaround results in reporting of incorrect null func status
for 10.4. Fix this is by introducing a firmware feature flag for 10.4
so that this workaround is skipped and proper tx status for null func
frames are reported
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There is only one waiter for the completion, therefore there
is no need to use complete_all(). Let's make that clear by
using complete() instead of complete_all().
The usage pattern of the completion is:
waiter context waker context
scan.started
------------
ath10k_start_scan()
lockdep_assert_held(conf_mutex)
auth10k_wmi_start_scan()
wait_for_completion_timeout(scan.started)
ath10k_wmi_event_scan_start_failed()
complete(scan.started)
ath10k_wmi_event_scan_started()
complete(scan.started)
scan.completed
--------------
ath10k_scan_stop()
lockdep_assert_held(conf_mutex)
ath10k_wmi_stop_scan()
wait_for_completion_timeout(scan.completed)
__ath10k_scan_finish()
complete(scan.completed)
scan.on_channel
---------------
ath10k_remain_on_channel()
mutex_lock(conf_mutex)
ath10k_start_scan()
wait_for_completion_timeout(scan.on_channel)
ath10k_wmi_event_scan_foreign_chan()
complete(scan.on_channel)
offchan_tx_completed
--------------------
ath10k_offchan_tx_work()
mutex_lock(conf_mutex)
reinit_completion(offchan_tx_completed)
wait_for_completion_timeout(offchan_tx_completed)
ath10k_report_offchain_tx()
complete(offchan_tx_completed)
install_key_done
----------------
ath10k_install_key()
lockep_assert_held(conf_mutex)
reinit_completion(install_key_done)
wait_for_completion_timeout(install_key_done)
ath10k_htt_t2h_msg_handler()
complete(install_key_done)
vdev_setup_done
---------------
ath10k_monitor_vdev_start()
lockdep_assert_held(conf_mutex)
reinit_completion(vdev_setup_done)
ath10k_vdev_setup_sync()
wait_for_completion_timeout(vdev_setup_done)
ath10k_wmi_event_vdev_start_resp()
complete(vdev_setup_done)
ath10k_monitor_vdev_stop()
lockdep_assert_held(conf_mutex)
reinit_completion(vdev_setup_done()
ath10k_vdev_setup_sync()
wait_for_completion_timeout(vdev_setup_done)
ath10k_wmi_event_vdev_stopped()
complete(vdev_setup_done)
thermal.wmi_sync
----------------
ath10k_thermal_show_temp()
mutex_lock(conf_mutex)
reinit_completion(thermal.wmi_sync)
wait_for_completion_timeout(thermal.wmi_sync)
ath10k_thermal_event_temperature()
complete(thermal.wmi_sync)
bss_survey_done
---------------
ath10k_mac_update_bss_chan_survey
lockdep_assert_held(conf_mutex)
reinit_completion(bss_survey_done)
wait_for_completion_timeout(bss_survey_done)
ath10k_wmi_event_pdev_bss_chan_info()
complete(bss_survey_done)
All complete() calls happen while the conf_mutex is taken. That means
at max one waiter is possible.
Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Recent commit 46f6b06050 ("mac80211: Encrypt "Group addressed privacy" action
frames") encrypts group privacy action frames. But qca99x0 family chipset
delivers broadcast/multicast management frames as encrypted and it should be
decrypted by mac80211. Setting RX_FLAG_DECRYPTED stats for those frames is
breaking mesh connection establishment.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
With the %pK format specifier we hide the kernel addresses
with the help of kptr_restrict sysctl.
In this patch, %p is changed to %pK in the driver code.
The sysctl is documented in Documentation/sysctl/kernel.txt.
Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW Rx filters and masks are not configured
properly by firmware during boot sequences. The
MAC_PCU_ADDR1 is set to 0s instead of 1s which
allows the HW to ACK any frame that passes through
MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself
is misconfigured on boot as well.
The combination of these bugs ended up with the
following manifestations:
- "no channel configured; ignoring frame(s)!"
warnings in the driver
- spurious ACKs (transmission) on the air during
firmware bootup sequences
The former was a long standing and known bug
originally though mostly harmless.
However Marek recently discovered that this
problem also involves ACKing *all* frames the HW
receives (including beacons ;). Such frames
are delivered to host and generate the former
warning as well.
This could be a problem with regulatory compliance
in some rare cases (e.g. Taiwan which forbids
transmissions on channel 36 which is the default
bootup channel on 5Ghz band cards). The good news
is that it'd require someone else to violate
regulatory first to coerce our device to generate
and transmit an ACK.
The problem could be reproduced in a rather busy
environment that has a lot of APs. The likelihood
could be increased by injecting an msleep() of
5000 or longer immediately after
ath10k_htt_setup() in ath10k_core_start().
The reason why the former warnings were only
showing up seldom is because the device was either
quickly reset again (i.e. during firmware probing)
or wmi vdev was created (which fixes hw and fw
states).
It is technically possible for host driver to
override adequate hw registers however this can't
work reliably because the bug root cause lies in
incorrect firmware state on boot (internal
structure used to program MAC_PCU_ADDR1 is not
properly initialized) and only vdev create/delete
events can fix it. This is why the patch takes
dummy vdev approach.
This could be fixed in firmware as well but having
this fixed in driver is more robust, most notably
when thinking of users of older firmware such as
999.999.0.636.
Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Preparation to make use of firmware_swap_code_seg_info for UTF binary.
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Print an ath10k error message rather a call trace when HTT op version is
not found from firmware META data (IE). This should be sufficient to figure
out what went wrong.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
QCA9888 shares the same configuration with QCA99X0
with NSS=2.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Several cases of overlapping changes, except the packet scheduler
conflicts which deal with the addition of the free list parameter
to qdisc_enqueue().
Signed-off-by: David S. Miller <davem@davemloft.net>
In QCA4019, cycle counter wraparound is not tied to rx
clear counter. Each counter would wraparound individually
and after wraparound the respective counter will be reset
to 0x7fffffff while other counter still running unaffected.
Define a new wraparound type for this behaviour and handle
it separately so that rx clear counter wraparound is also
handled just like cycle counter. With this type of
wraparound we can accurately compute and report channel
active/busy time when any of the counter overflows.
Fixes: ee9ca147c5 ("ath10k: Fix survey reporting with QCA4019")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
QCA988X hw implements a different cycle counter wraparound
behaviour when compared to QCA4019. To properly handle different
wraparound logic for these chipsets replace already available
bool hw_params member, has_shifted_cc_wraparound, with an
enum which could be extended to handle different wraparound
behaviour. This patch keeps the existing logic functionally
same and a prepares cycle counter wraparound handling to
extend for other chips.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: change also QCA9887 wrap type]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below
ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,
This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This looks like a regression from commit c4cdf753ed ("ath10k: move
fw_features to struct ath10k_fw_file"), we were printing the features from a
wrong struct.
Fixes: c4cdf753ed ("ath10k: move fw_features to struct ath10k_fw_file")
Signed-off-by: Ben Greear <greearb@candelatech.com>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The QCA9887 stores its calibration data (board.bin) inside the EEPROM of
the target. This has to be downloaded manually to allow the device to
initialize correctly.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
[kvalo@qca.qualcomm.com: handle -EOPNOTSUPP and s/fetch_board_data/fetch_cal_eeprom]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add the hardware name, revision, firmware names and update the pci_id
table.
QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
he firmware interface are currently unknown.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
[kvalo@qca.qualcomm.com: add a warning about experimental support]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
10.4 firmware has support to enable or disable btcoex functionality
without reloading firmware via wmi pdev param. Add provision to send
pdev param command via existing btcoex knob.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This feature flag will be used for firmware to support BT-Coex feature
without reloading firmware via WMI pdev param. To support Bluetooth
coexistence pdev param, WMI_COEX_GPIO_SUPPORT of extended resource
config should be enabled always. This firmware IE is used to configure
WMI_COEX_GPIO_SUPPORT.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Update module description to advertise all supported QCA 802.11ac devices.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
QCA9984 shares the same configuration with QCA99X0.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In QCA4019, cycle counter wraparound in same fashion
as QCA988X. When the cycle counter wraparound it
resets to 0x7fffffff. Set has_shifted_cc_wraparound to
true for QCA4019 to enable the code path to handle cycle
counter wraparound for consistent survey report.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
During hw scan, firmware sends two channel information events (pre-
complete, complete) to host for each channel change. The snap shot of cycle
counters (rx_clear and total) between these two events are given for
survey dump. In order to get latest survey statistics of all channels, a
scan request has to be issued. In general, an AP DUT is brought up, it
won't leave BSS channel except few cases like overlapping bss or radar
detection. So survey statistics of bss channel is always referring to
older data that are collected before starting AP (either ACS/OBSS scan).
To collect latest survey information from target, firmware provides WMI
interface to read cycle counters from hardware. For each survey dump
request, BSS channel cycle counters are read and cleared in hardware.
This makes sure that behavior is in align with ath9k survey report.
So survey dump always gives snap shot of cycle counters b/w two survey
requests.
Signed-off-by: Yanbo Li <yanbol@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is observed that while loading and unloading ath10k modules
in an infinite loop, before ath10k_core_start() completion HTT
rx frames are received, while processing these frames,
dereferencing the arvifs list code is getting hit before
initilizing the arvifs list, causing a kernel panic.
This patch initilizes the arvifs list before initilizing htt.
Fixes the below issue:
[<bf88b058>] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 [ath10k_core])
[<bf88b058>] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core])
[<bf88c0dc>] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core])
[<bf88c0dc>] (ath10k_htt_txrx_compl_task [ath10k_core])
[<c0234100>] (tasklet_action+0x8c/0xec)
[<c0234100>] (tasklet_action)
[<c02337c0>] (__do_softirq+0xf8/0x228)
[<c02337c0>] (__do_softirq) [<c0233920>] (run_ksoftirqd+0x30/0x90)
Code: e5954ad8 e2899008 e1540009 0a00000d (e5943008)
---[ end trace 71de5c2e011dbf56 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 500ff9f938 ("ath10k: implement chanctx API")
Cc: <stable@vger.kernel.org>
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Now that all firmware-N.bin related are within struct ath10k_fw_file we can
switch to use ath10k_core_fetch_firmware_api_n() and delete almost identical
ath10k_tm_fetch_utf_firmware_api_2().
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
To make it easier to share ath10k_core_fetch_board_data_api_n() with testmode.c
refactor all firmware components to struct ath10k_fw_components. This structure
will hold firmware related files, for example firmware-N.bin and board-N.bin.
For firmware-N.bin create a new struct ath10k_fw_file which contains the actual
firmware image as well as the parsed data from the image.
Modify ath10k_core_start() to take struct ath10k_fw_components() as an argument
which makes it possible in following patches to drop some ugly hacks from
testmode.c.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This has ben deprecated years ago, I haven't heard anyone using it since and
most likely it won't even work anymore. So just remove all of it.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
push-pull mode needs certain amount the host driver involvement for
managing queues in the host memory and packet delivery to firmware.
qca4019 wifi firmware has an option to stay in push mode for less
number of active traffic flow and then switch to push-pull mode when
the active traffic flow goes beyond the certain limit.
The advantage of staying in push mode for less active traffic is, the
host cpu consumption is reduced. qca4019 firmware supports this
flexibility of the mode switch. It takes the host driver interest
(LOW_PERF/HIGH_PERF) via WMI_EXT_RESOURCE_CFG_CMDID,
LOW_PERF - fw would stay in push mode and switch to push-pull
based on demand.
HIGH_PERF - fw would stay in push-pull mode from the boot.
To make this configuration generic, new WMI services
WMI_SERVICE_TX_MODE_PUSH_ONLY, WMI_SERVICE_TX_MODE_PUSH_PULL,
WMI_SERVICE_TX_MODE_DYNAMIC are introduced to take dynamic tx mode
switch support availability in firmware.
Based on WMI_SERVICE_TX_MODE_DYNAMIC, LOW_PERF or HIGHT_PERF is
configured to the firmware.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Rx duration support for per station is part of extended peer
stats, enable provision to parse the same and provide backward
compatibility based on the 'stats_id' event
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Provide a debugfs entry to enable/ disable Peer Stats feature.
Peer Stats feature is for developers/users who are more interested
in studying in Rx/Tx stats with multiple clients connected, hence
disable this by default. Enabling this feature by default results
in unneccessary processing of Peer Stats event for every 500ms
and updating peer_stats list (allocating memory) and cleaning it up
ifexceeds the higher limit and this can be an unnecessary overhead
during long run stress testing.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
qca4019 calibration data is stored in the host memory and it's mandatory
to download it even before reading board id and chip id from the target.
Also, there is a need to execute otp (download and run) twice, one after
cal data download and another one after board data download.
Existing cal data file name 'cal-<bus>-<id>.bin' and device tree entry
'qcom,ath10k-calibration-data' used in ath10k has assumption that it
carries other data (like board data) also along with the calibration data.
But, qca4019 cal data contains pure calibration data (doesn't include
any other info). So, using existing same cal file name and DT entry
in qca4019 case would alter the purpose of it. To avoid this, new cal
file name 'pre-cal-<bus>-<id>.bin' and new device tree entry name
'qcom,ath10k-pre-calibration-data are introduced.
Overall qca4019's firmware download sequence would look like,
1) Download cal data (either from a file or device tree entry)
at the address specified by target in the host interest area
member "hi_board_data".
2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID)
as a argument.
At this point, otp will take back up of downloaded cal data
content in another location in the target and return valid
board id and chip id to the host.
3) Download board data at the address specified by target
in host interest area member "hi_board_data".
4) Download otp and run with 0x10000 (PARAM_FLASH_SECTION_ALL) as
a argument.
Now otp will apply cal data content from it's backup on top
of board data download in step 3 and prepare final data base.
5) Download code swap and athwlan binary content.
Above sequences are implemented (step 1 to step 4) in the name of
pre calibration configuration.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k_download_cal_dt() compares obtained cal data content length
against QCA988X_CAL_DATA_LEN (2116 bytes). It was written by keeping
qca988x in mind. In fact, cal data length is more chip specific.
To make ath10k_download_cal_dt() more generic and reusable for other
chipsets (like qca4019), cal data length is moved to hw_params.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Both ath10k_download_cal_file() and ath10k_download_cal_dt() uses
hard coded file pointer (ar->cal_file) and device tree entry
(qcom,ath10k-calibration-data) respectively to get calibration
data content.
There is a need to use those two functions in qca4019 calibration
download sequence with different file pointer and device tree entry name.
Modify those two functions to take cal data location as an argument.
So that it can serve the purpose for other file pointer and device
tree entry.
This is just preparation before adding actual qca4019 calibration
download sequence. No functional changes.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k_core_probe_fw() simply returns error without freeing
cached firmware file content when get board id operation fails.
Free cached fw bin data in failure case to avoid memory leak.
Fixes: db0984e51a ("ath10k: select board data based on BMI chip id and board id")
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
