This is necessary to make vdev restarting logic
reusable later.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The remain_on_channel callback needs different
timeout. Calling ieee80211_queue_work() with a
shorter delay after calling it with a longer delay
will not change the timer. This caused the
offchannel timeout worker to not trigger in time
and caused the device to stay on channel longer
then expected. This could cause some problems and
was be easily reproduced with `iw offchannel`
command.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add support for mesh to ath10k. We simply use an AP virtual interface
in the firmware in order to enable beaconing without TSF adoption, and
use the raw (802.11) transmit mode.
Due to firmware limitations, the firmware must operate in raw
(non-native 802.11) mode. As this is configured at firmware init time,
a new "rawmode" modparam is added, and mesh interfaces are available
only if rawmode=true. The firmware must advertise support for rawmode;
tested successfully with firmware 10.2.4.70.6-2.
When the module is loaded with (newly implemented) modparam rawmode=1, it
will enable operating an open mesh STA via something like the following:
ip link set wlan0 down
iw dev wlan0 set type mp
ip link set wlan0 up
iw dev wlan0 set freq 5745 80 5775
iw dev wlan0 mesh join mesh-vht
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In the case of raw mode without nohwcrypt parameter, we
should still make sure the frame is protected before
adding MIC_LEN to avoid skb_under_panic errors.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
By default, ath10k restricts received frames to those matching BSSID.
When other BSS frames are requested (e.g. in mesh mode), add an internal
monitor device so those frames are not filtered.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Sometimes hardware reports invalid mcs index in rx descriptor
when operating in VHT80 mode and all packets with invalid mcs
will be eventually dropped in mac80211. This issue is observerd during
testing on QCA99X0 chipsets.
This patch adds a warn message for dumping the rx desc info which helps
in analysing the issue when invalid mcs is received.
Signed-off-by: Manikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Similarly to the VHT STS, this is supposed to be propagated by firmware.
In case it's not, use the default value, but as last resort.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The VHT STS CAP shall be reported by firmware to host, like in case of
QCA99x0. For QCA6174 hw family this isn't set for some reason.
So for this particular chips, let's assume it has the ability to
support VHT NDP in up to 4 STSs (which is true by the way).
Change the published beamformee STS cap accordingly to 3 or to what
the firmware reports.
Assumption so far, it suppose to be the num_rf_chains-1, was
completely wrong.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In a noisy environment, when multiple interfaces are created,
the management tx descriptors are fully occupied by the probe
responses from all the interfaces. This prevents a new station
from a successful association.
Fix this by limiting the probe responses when the specified
threshold limit is reached.
Signed-off-by: Vivek Natarajan <nataraja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
During long hours of stress testing like AP interface up/down along
with continuous ping flood from a station doing connect/disconnect,
it is observed that the system is not able to allocate DMA consistent
memory of size > 512KB chunks as requested by firmware in WMI_SERVICE_EVENTID.
With the system memory getting fragmented during the run based on the
size of the memory requested, the failure to return physically continguous
memory of high order can happen. Once the system gets to this situation,
bringing up the wifi interface will fail and a system reboot may be needed
to make it work again. This problem is obseved with QCA99X0.
To fix this issue, allocate the DMA memory requested by firmware during
device probe time and keep it during the life time of the device. WMI service
ready event handler is changed to allocate the memory chunks if it is
not already allocated or if the memory allocated for the previous ready
event is not same as the current requested ones. After this patch the
memory usage when wifi is inactive will be inceased by few 100KB to
3MB based on the target type.
Failure happens with the following stack trace
[29557.488773] kworker/u4:1: page allocation failure: order:8, mode:0xd0
[29557.494297] CPU: 0 PID: 8402 Comm: kworker/u4:1 Not tainted 3.14.43 #7
[29557.500793] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
[29557.508602] [<c021e9b0>] (unwind_backtrace) from [<c021ba90>] (show_stack+0x10/0x14)
[29557.516580] [<c021ba90>] (show_stack) from [<c03bdddc>] (dump_stack+0x88/0xcc)
[29557.523612] [<c03bdddc>] (dump_stack) from [<c0290e34>] (warn_alloc_failed+0xdc/0x108)
[29557.531515] [<c0290e34>] (warn_alloc_failed) from [<c0292d88>] (__alloc_pages_nodemask+0x4f0/0x654)
[29557.540485] [<c0292d88>] (__alloc_pages_nodemask) from [<c0222b48>] (__dma_alloc_buffer.isra.20+0x2c/0x104)
[29557.550260] [<c0222b48>] (__dma_alloc_buffer.isra.20) from [<c0222c34>] (__alloc_remap_buffer.isra.23+0x14/0xb8)
[29557.560413] [<c0222c34>] (__alloc_remap_buffer.isra.23) from [<c022305c>] (__dma_alloc+0x224/0x2b8)
[29557.569490] [<c022305c>] (__dma_alloc) from [<c0223208>] (arm_dma_alloc+0x84/0x90)
[29557.577010] [<c0223208>] (arm_dma_alloc) from [<bf5159d0>] (ath10k_wmi_event_service_ready_work+0x2f8/0x420 [ath10k_core])
[29557.588055] [<bf5159d0>] (ath10k_wmi_event_service_ready_work [ath10k_core]) from [<c024260c>] (process_one_work+0x20c/0x328)
[29557.599305] [<c024260c>] (process_one_work) from [<c02432d0>] (worker_thread+0x228/0x360)
[29557.607470] [<c02432d0>] (worker_thread) from [<c0247f88>] (kthread+0xd8/0xec)
[29557.614750] [<c0247f88>] (kthread) from [<c0208d18>] (ret_from_fork+0x14/0x3c)
[29557.712751] Normal: 696*4kB (UEMR) 512*8kB (UEMR) 367*16kB (UEMR) 404*32kB (UEMR) 455*64kB (UEMR) 424*128kB (UEMR) 379*256kB (UMR) 327*512kB (UMR) 1*1024kB (R) 0*2048kB 0*4096kB = 374544kB
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
MU-MIMO Rx involves different interpretation of
the VHT-SIG-A compared to SU-MIMO.
The incorrect interpretation led ath10k to report
VHT MCS values greater than 9 which subsequently
prompted mac80211 to drop such frames. This
effectively broke Rx with MU-MIMO in many cases
and manifested with a kernel warning in the log
which looked like this:
[ 14.552520] WARNING: CPU: 2 PID: 0 at net/mac80211/rx.c:3578 ieee80211_rx+0x26c/0x940 [mac80211]()
[ 14.552522] Rate marked as a VHT rate but data is invalid: MCS: 10, NSS: 2
... call trace follows ...
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Below compilation warnings are observed in gcc version 4.8.2.
Even though it's not seen in bit older gcc versions (for ex, 4.7.3),
It's good to fix it by changing format specifier from %d to
%zd in wmi pull phyerr functions.
wmi.c: In function 'ath10k_wmi_op_pull_phyerr_ev':
wmi.c:3567:8: warning: format '%d' expects argument of type 'int',
but argument 4 has type 'long unsigned int' [-Wformat=]
left_len, sizeof(*phyerr));
^
wmi.c: In function 'ath10k_wmi_10_4_op_pull_phyerr_ev':
wmi.c:3612:8: warning: format '%d' expects argument of type 'int',
but argument 4 has type 'long unsigned int' [-Wformat=]
left_len, sizeof(*phyerr));
^
Fixes: 991adf71a6 ("ath10k: refactor phyerr event handlers")
Fixes: 2b0a2e0d7c ("ath10k: handle 10.4 firmware phyerr event")
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This adds additional 0x0041 PCI Device ID
definition to ath10k for QCA6164 which is a 1
spatial stream sibling of the QCA6174 (which is 2
spatial stream chip).
The QCA6164 needs a dedicated board.bin file which
is different than the one used for QCA6174. If the
board.bin is wrong the device will crash early
while trying to boot firmware. The register dump
will look like this:
ath10k_pci 0000:02:00.0: firmware register dump:
ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31
...
Note the value 0x000A012D.
Special credit goes to Alan Liu
<alanliu@qca.qualcomm.com> for providing support
help which enabled me to come up with this patch.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
To enable/configure spectral scan parameters in 10.4 firmware, existing
wmi spectral related functions can be reused. Link those functions in
10.4 wmi ops table.
In addition, adjust bin size (only when size is 68 bytes) before reporting
bin samples to user space. The background for this adjustment is that
qca99x0 reports bin size as 68 bytes (64 bytes + 4 bytes) in report
mode 2. First 64 bytes carries in-band tones (-32 to +31) and last 4 byte
carries band edge detection data (+32) mainly used in radar detection
purpose. Additional last 4 bytes are stripped to make bin size valid one.
This bin size adjustment will happen only for qca99x0, all other chipsets
will report proper bin sizes (64/128) without extra 4 bytes being added
at the end. The changes are validated in qca99x0 using 10.4 firmware.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The function returns 1 when DMA mapping fails. The
driver would return bogus values and could
possibly confuse itself if DMA failed.
Fixes: 767d34fc67 ("ath10k: remove DMA mapping wrappers")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Kernel would complain about leaving a held lock
after going back to userspace and would
subsequently deadlock.
Fixes: e04cafbc38 ("ath10k: fix peer limit enforcement")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If .pull_fw_stats() fails for some reason while processing
fw stats event, collected pdev/vdev/peer stats just before
the failure should be freed. This is unlikely to happen,
just code review catch.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Found incorrect sequence in ath10k_core_stop() where wmi pktlog
disable cmd is passed from ath10k_debug_stop() to firmware
immediately after wmi pdev suspend cmd. Firmware will not accept
any wmi cmd after receiving wmi pdev suspend cmd.
Fix this issue in ath10k_core_stop() by moving ath10k_debug_stop()
just before sending pdev suspend cmd. So that pktlog disable cmd
will get passed before pdev suspend cmd.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
WMI 10.4 uses the same command interface as QCA988X for addba/delba
debug wmi commands. Fill wmi_10_4_ops table with the functions used
for QCA988X for these commands.
With this change, the following debugfs entries can be used to
configure the aggregation mode and to send addba request,
addba response and delba respectively in manual aggregation mode
for QCA99X0 chip.
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/aggr_mode
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/addba
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/addba_resp
/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/XX:XX:XX:XX:XX:XX/delba
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Header format of 10.4 firmware phyerr event is not alligned
with pre 10.4 firmware. Introduce new wmi handlers to parse
10.4 firmware specific phyerror event header.
With changes covered in this patch, radar detection works on
qca9x0 hw 2.0 which uses 10.4 firmware.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Existing phyerr event handlers directly uses phyerr header format
(ie, struct wmi_phyerr and struct wmi_phyerr_event) in the code
exactly on how firmware packs it. This is the problem in 10.4 fw
specific phyerr event handling where it uses different phyerror
header format. Before adding 10.4 specific handler, little bit of
refactor is done in existing phyerr handlers.
Two new abstracted structures (struct wmi_phyerr_ev_hdr_arg and
struct wmi_phyerr_ev_arg) are introduced to remove dependency of using
firmware specific header format in the code. So that firmware specific
phyerror handlers can populate values to abstracted structures and
the following code can use abstracted struct for further operation.
.pull_phyerr_hdr is added newly to pull common phyerr header info
like tsf, buf_len, number of phyerr packed. Existing .pull_phyerr
handler is changed and called to parse every sub phyerrs in the event.
Validated these refactoring on qca988x hw2.0 using fw 10.2.4 version.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Apparently it's not safe to install both pairwise
and groupwise keys on AP vdevs as it can cause
traffic to stop working in some multi-vif
(WPA+WEP) cases.
Fixes: ce90b27128 ("ath10k: fix multiple key static wep with ibss")
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The frequency at which cycle/rx_clear counters are running might
change from one target type to another. QCA99X0 is running the
counters at 150Mhz while QCA9888X and QCA6174 are running at 88Mhz.
Add a new entry to hw_params to store the target specific frequency
and use it in msecs conversion. This change fixes inconsistent
channel active/busy time.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There are three WMI_CHAN_INFO events reported per channel
in QCA99X0 firmware. First one is a notification at the begining
of the channel dwell time with cmd_flag as CHAN_INFO_START(cmd_flag = 0),
second one is a notification at the end of the dwell time with cmd_flag
CHAN_INFO_PRE_COMPLETE (cmd_flag = 2) and the third is the indication
with CHAN_INFO_COMPLETE (cmd_flag = 1) which is the last indication for
the channel. Since there is a new state before the completion, the handler
is to fixed so that the counts are deducted from the ones reported with
CHAN_INFO_START rather than the ones reported with CHAN_INFO_PRE_COMPLETE.
Without this fix there will be lots of 0 msecs reported as active
and busy time.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Vif's vdev_id is used as queue number. However due
to the tx pausing design in ath10k it was possible
for a new interface to be created with its tx
queue stopped (via ieee80211_stop_queues). This
could in turn leave the interface inoperable until
ath10k_mac_tx_unlock() was called.
This problem only affected multi-vif scenarios when
new interfaces were created some time later after
other interfaces have been running for some time
and had Tx queue full at some point prior.
Possible manifestation of the bug was
authentication timeout for a client vif.
Fixes: 96d828d45e ("ath10k: rework tx queue locking")
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Once HTT Tx queue got full offchannel queue was
stopped and never woken up again. This broke, e.g.
P2P. This could be reproduced after running a lot
of traffic enough to saturate 100% of the driver
Tx queue and then trying to send offchannel
traffic.
Fixes: 96d828d45e ("ath10k: rework tx queue locking")
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Firmware peer entries are involved in internal
firmware vdev structures. This was not accounted
for and could lead firmware to crash due to asking
it to do more than it could.
Fixes: 039a0051ec ("ath10k: allocate fw resources for iface combinations")
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If peer creation failed during offchannel Tx the
driver attempted to delete the peer nonetheless.
This caused the ar->num_peers counter to be
incorrectly decremented. This subsequently could
cause the counter to drop below 0 and also
eventually lead to firmware crash because host
would think there are less peer entries created in
firmware then there really were.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When WoWLAN resume fails with retval 1 mac80211
will attempt to reconfig the device in a similar
manner when hw restart is requested. This wasn't
handled properly and yielded call trace warnings
and the device ended up not working.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If firmware did not have any feature flags set the
var would be left with values found on the stack
(i.e. garbage) yielding print string like this:
(...) features \xffffffa6m:^R\xfffffffbԂ\xffffffc4^E
Fixes: b27bc5a40f ("ath10k: dump fw features during probing")
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch enables MU-MIMO transmit beamforming support
for QCA99X0 chipsets.
Signed-off-by: Vivek Natarajan <nataraja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
qca61x4 uses the vdev param as a sole sufficient configuration
for txbf while qca99x0 enables txbf during peer assoc by
combining the vdev param value with peer assoc's vht capabilities
This patch gets the appropriate txbf configuration scheme
before passing the wmi command to enable the same in the firmware.
Signed-off-by: Vivek Natarajan <nataraja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Even though there's a WMI enum for fragmentation
threshold no known firmware actually implements
it. Moreover it is not possible to rely frame
fragmentation to mac80211 because firmware clears
the "more fragments" bit in frame control making
it impossible for remote devices to reassemble
frames.
Hence implement a dummy callback just to say
fragmentation isn't supported. This effectively
prevents mac80211 from doing frame fragmentation
in software.
This fixes Tx becoming broken after setting
fragmentation threshold.
Fixes: 1010ba4c5d ("ath10k: unregister and remove frag_threshold callback")
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Commit 1010ba4c5d ("ath10k: unregister and
remove frag_threshold callback") didn't remove all
instances of (futile) fragmentation threshold
configuration. No known firmware supports the
parameter so don't even bother setting it.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Initial QCA99X0 support has a known issue with TCP Tx throughput.
All other path such as UDP Tx/Rx and TCP Rx meet their expectation
(> 900Mbps), but TCP Tx marked as low as 5Mbps when single pair is
used on iperf.
The root cause is turned out because TSO flag is not initialized
properly so that firmware configures TSO in wrong way.
TSO flags in msdu extension descriptor is required to be reset
to indicate firmware there is no TSO is enabled, otherwise it
could act as TSO is enabled which causes huge throughput drop.
In fact, it's enough by resetting TSO flags only to prevent the
unexpected behavior, but initializing whole msdu ext. descriptor
will help to clear uncertainty of firmware could bring on as it
constantly updated.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add vendor/device id of QCA99X0 V2.0 to pci id table and
QCA99X0_HW_2_0_CHIP_ID_REV to ath10k_pci_supp_chips[] for
QCA99X0 to get detected by the driver.
kvalo: now QCA99X0 family of chipsets is supported by ath10k.
Tested client, AP and monitor mode with QCA9990.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When max client was set to 512 in qca99x0, there was host memory
alloc failure during wmi service ready event handling. This issue
got resolved now, increasing max client limit from 256 to 512.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Host memory required for firmware is allocated while handling
wmi service ready event. Right now, wmi service ready is handled
in tasklet context and it calls dma_alloc_coherent() with atomic
flag (GFP_ATOMIC) to allocate memory in host needed for firmware.
The problem is, dma_alloc_coherent() with GFP_ATOMIC fails in
the platform (at least in AP platform) where it has less atomic
pool memory (< 2mb). QCA99X0 requires around 2 MB of host memory
for one card, having additional QCA99X0 card in the same platform
will require similarly amount of memory. So, it's not guaranteed that
all the platform will have enough atomic memory pool.
Fix this issue, by handling wmi service ready event in workqueue
context and calling dma_alloc_coherent() with GFP_KERNEL. mac80211 work
queue will not be ready at the time of handling wmi service ready.
So, it can't be used to handle wmi service ready. Also, register work
gets scheduled during insmod in existing ath10k_wq and waits for
wmi service ready to completed. Both workqueue can't be used for
this purpose. New auxiliary workqueue is added to handle wmi service
ready.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch enables raw Rx/Tx encap mode to support software based
crypto engine. This patch introduces a new module param 'cryptmode'.
cryptmode:
0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
encapsulation to the firmware. This is the default mode.
1: Use sofware crypto engine globally with raw mode TX/RX
encapsulation to the firmware.
Known limitation:
A-MSDU must be disabled for RAW Tx encap mode to perform well when
heavy traffic is applied.
Testing: (by Michal Kazior <michal.kazior@tieto.com>)
a) Performance Testing
cryptmode=1
ap=qca988x sta=killer1525
killer1525 -> qca988x 194.496 mbps [tcp1 ip4]
killer1525 -> qca988x 238.309 mbps [tcp5 ip4]
killer1525 -> qca988x 266.958 mbps [udp1 ip4]
killer1525 -> qca988x 477.468 mbps [udp5 ip4]
qca988x -> killer1525 301.378 mbps [tcp1 ip4]
qca988x -> killer1525 297.949 mbps [tcp5 ip4]
qca988x -> killer1525 331.351 mbps [udp1 ip4]
qca988x -> killer1525 371.528 mbps [udp5 ip4]
ap=killer1525 sta=qca988x
qca988x -> killer1525 331.447 mbps [tcp1 ip4]
qca988x -> killer1525 328.783 mbps [tcp5 ip4]
qca988x -> killer1525 375.309 mbps [udp1 ip4]
qca988x -> killer1525 403.379 mbps [udp5 ip4]
killer1525 -> qca988x 203.689 mbps [tcp1 ip4]
killer1525 -> qca988x 222.339 mbps [tcp5 ip4]
killer1525 -> qca988x 264.199 mbps [udp1 ip4]
killer1525 -> qca988x 479.371 mbps [udp5 ip4]
Note:
- only open network tested for RAW vs nwifi performance comparison
- killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
- used iperf
- OTA, devices a few cm apart from each other, no shielding
- tcpX/udpX, X - means number of threads used
Overview:
- relative Tx performance drop is seen but is within reasonable and
expected threshold (A-MSDU must be disabled with RAW Tx)
b) Connectivity Testing
cryptmode=1
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK
Note:
- each test takes all possible endpoint pairs and pings
- each pair-ping flushes arp table
- ip6 is used
c) Testbed Topology:
1ap1sta:
[ap] ---- [sta]
endpoints: ap, sta
1ap1sta2br:
[veth0] [ap] ---- [sta] [veth2]
| | | |
[veth1] | \ [veth3]
\ / \ /
[br0] [br1]
endpoints: veth0, veth2, br0, br1
note: STA works in 4addr mode, AP has wds_sta=1
1ap1sta2br1vlan:
[veth0] [ap] ---- [sta] [veth2]
| | | |
[veth1] | \ [veth3]
\ / \ /
[br0] [br1]
| |
[vlan0_id2] [vlan1_id2]
endpoints: vlan0_id2, vlan1_id2
note: STA works in 4addr mode, AP has wds_sta=1
Credits:
Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
amsdu issue, contributed a workaround (already squashed into this
patch), and contributed the throughput and connectivity tests results.
Signed-off-by: David Liu <cfliu.tw@gmail.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Tested-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
During tx completion, tx_lock is held for longer than required, preventing
efficient refill of htt->pending_tx. Refactor the code so that only MSDU
related operations are protected by the lock.
Improves downstream performance on a dual-core ARM Freescale LS1024A
(f.k.a. Mindspeed Comcerto 2000) AP with a 3x3 client from 495 to 580 Mbps.
Other CPU bound multicore systems may also benefit.
Signed-off-by: Denton Gentry <dgentry@google.com>
Signed-off-by: Avery Pennarun <apenwarr@google.com>
[mfaltesek@google.com: removed conflicting code for tracking msdu_ids.]
Signed-off-by: Marty Faltesek <mfaltesek@google.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When using DFS channels on Ath10k, kernel log has repeated warning message
'failed to process fft: -22' typically under medium/heavy traffic.
This patch switches the warnings to driver debug (WMI events) mode only
thus reducing log file noise.
DFS and spectral scan share underlying HW mechanisms and enabling one
(DFS) enables the other (spectral scan) as far as event reporting from
firmware to driver is concerned. Spectral scan events take no part in
processing of DFS radar pulses which are delivered as distinct events,
so the fft (spectral event) warning is harmless and DFS interference
detection/protection still occurs.
Symptoms seen & fix tested in both debug & non-debug modes on TP-Link
Archer C7 v2 platform.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HTT_H2T_MSG_TYPE_MGMT_TX msg in 10.4 firmware carries additional
4 byte in htt_mgmt_tx_desc where it tells to firmware that at what
rate mgmt frame has to go out in the air. It's an optional parameter,
setting this field to zero will force firmware to choose auto rate
and send the frame out.
Those 4 byte info is missed out in the current code and 10.4 firmware
ended up reading some junk in those 4 byte and sometime malfunctioning.
Fix it by adding 4 byte in struct htt_mgmt_tx_desc. Non 10.4 firmware
will not process those four byte. So, adding 4 byte at the end of
struct htt_mgmt_tx_desc will not create any impact on other chipset.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The patch adds support to offload TCP/UDP checksum
calculations for QCA99x0.
Signed-off-by: Manikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
chandef is initialized with NULL and on the very next line, we are using it to
get channel, which is not correct. Channel should be initialized after
obtaining chandef.
Found by cppcheck:
ath/ath10k/mac.c:839]: (error) Possible null pointer dereference: chandef
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
QCA99X0 chip has an extra 4 bytes in rx_msdu_start,
20 bytes in rx_msdu_end and 20 bytes in rx_ppdu_end structure
which are used in htt_rx_desc and HTT Rx ring offset setup.
This is necessary for correct Rx for QCA99X0 or Rx descriptors
will be overwritten and corrupted.
With this patch QCA988X and QCA6174 will have extra 44 bytes
padding in Rx descriptor layout which is harmless.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
rx_ppdu_end_common structure is valid for both of qca998x and
qca6174, but not for qca99x0 since it has new additional members.
Hence update the common structure to cover qca99x0 as well.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Since QCA99X0 uses fragmentation descriptor differently from
other ones on tx path, we need to handle it separately.
QCA99X0 is using 48 bits for address and 16 bits for length
out of 2 dword and each values have to be programmed by frag
desc base addr + msdu id, so that hardware can retrieve
corresponding frag data.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is observed that during cold reset pcie access right
after a write operation to SOC_GLOBAL_RESET_ADDRESS causes
Data Bus Error and system hard lockup. The reason
for bus error is that pcie needs some time to get
back to stable state for any transaction during cold reset. Add
delay of 20 msecs after write of SOC_GLOBAL_RESET_ADDRESS
to fix this issue. This patch is tested on QCA988X. This is
also tested on QCA99X0 which is WIP.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Concurrent AP/GO operation on different channels
isn't really supported well by the firmware so
it's better to remove it from being advertised.
Also tune the way station and p2p client interface
limits are expressed to allow station + 2x p2p
client or station + p2p client + p2p go.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
