While debugging driver crashes related to a buggy firmware
crashing under load, I noticed that ath10k_htt_rx_ring_free
could be called without being under lock. I'm not sure if this
is the root cause of the crash or not, but it seems prudent to
protect it.
Originally tested on 4.16+ kernel with ath10k-ct 10.4 firmware
running on 9984 NIC.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Added for the same reason as the TX wrappers.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch add support to get RSSI from acknowledgment
frames for transmitted management frames.
hardware_used: QCA4019, QCA9984.
firmware version: 10.4-3.5.3-00052.
Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
the index of RATE_INFO_BW_20, but the updates to ath10k missed
the special bandwidth calculation case in
ath10k_update_per_peer_tx_stats().
This will fix below warning,
WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254
cfg80211_calculate_bitrate+0x174/0x220
invalid rate bw=1, mcs=9, nss=2
(unwind_backtrace) from
(cfg80211_calculate_bitrate+0x174/0x220)
(cfg80211_calculate_bitrate) from
(nl80211_put_sta_rate+0x44/0x1dc)from
(nl80211_put_sta_rate) from
(nl80211_send_station+0x388/0xaf0)
(nl80211_get_station+0xa8/0xec)
[ end trace da8257d6a850e91a ]
Fixes: 842be75c77 ("cfg80211: make RATE_INFO_BW_20 the default")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Added per tid sta counters for the following
- Total number MSDUs received from firmware
- Number of MSDUs received with errors like decryption, crc, mic ,etc.
- Number of MSDUs dropped in the driver
- A-MPDU/A-MSDU subframe stats
- Number of MSDUS passed to mac80211
All stats other than A-MPDU stats are only for received data frames.
A-MPDU stats might have stats for management frames when monitor
interface is active where management frames are notified both in wmi
and HTT interfaces.
These per tid stats can be enabled with tid bitmask through a debugfs
like below
echo <tid_bitmask> > /sys/kernel/debug/ieee80211/phyX/ath10k/sta_tid_stats_mask
tid 16 (tid_bitmask 0x10000) is used for non-qos data/management frames
The stats are read from
/sys/kernel/debug/ieee80211/phyX/netdev\:wlanX/stations/<sta_mac>/dump_tid_stats
Sample output:
To enable rx stats for tid 0, 5 and 6,
echo 0x00000061 > /sys/kernel/debug/ieee80211/phy0/ath10k/sta_tid_stats_mask
cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan15/stations/8c\:fd\:f0\:0a\:8e\:df/dump_tid_stats
Driver Rx pkt stats per tid, ([tid] count)
------------------------------------------
MSDUs from FW [00] 2567 [05] 3178 [06] 1089
MSDUs unchained [00] 0 [05] 0 [06] 0
MSDUs locally dropped:chained [00] 0 [05] 0 [06] 0
MSDUs locally dropped:filtered [00] 0 [05] 0 [06] 0
MSDUs queued for mac80211 [00] 2567 [05] 3178 [06] 1089
MSDUs with error:fcs_err [00] 0 [05] 0 [06] 2
MSDUs with error:tkip_err [00] 0 [05] 0 [06] 0
MSDUs with error:crypt_err [00] 0 [05] 0 [06] 0
MSDUs with error:peer_idx_inval [00] 0 [05] 0 [06] 0
A-MPDU num subframes upto 10 [00] 2567 [05] 3178 [06] 1087
A-MPDU num subframes 11-20 [00] 0 [05] 0 [06] 0
A-MPDU num subframes 21-30 [00] 0 [05] 0 [06] 0
A-MPDU num subframes 31-40 [00] 0 [05] 0 [06] 0
A-MPDU num subframes 41-50 [00] 0 [05] 0 [06] 0
A-MPDU num subframes 51-60 [00] 0 [05] 0 [06] 0
A-MPDU num subframes >60 [00] 0 [05] 0 [06] 0
A-MSDU num subframes 1 [00] 2567 [05] 3178 [06] 1089
A-MSDU num subframes 2 [00] 0 [05] 0 [06] 0
A-MSDU num subframes 3 [00] 0 [05] 0 [06] 0
A-MSDU num subframes 4 [00] 0 [05] 0 [06] 0
A-MSDU num subframes >4 [00] 0 [05] 0 [06] 0
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
paddrs_ring_64 holds the physical device address of the
rx buffers that host SW provides for the MAC HW to fill.
Since this field is used in rx ring setup and rx ring
replenish in rx data path. Define separate methods
for handling 64 bit ring paddr and attach them dynamically
based on target_64bit hw param flag. Use u64 type
while popping paddr from the rx hash table for 64bit target.
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
WCN3990 uses larger ring size in comparison to existing
ring size value.
Add rx ring size hw param for supporting different rx ring
size across multiple target.
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
WCN3990 target use 64bit msdu address in htt in-order
indication message. Add support for 64 bit msdu address in
HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND message.
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
10.2.4 firmware branch (used in QCA988X) does not support
HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide
tranmission rate statistics to user space, instead it just shows
hardcoded 6 Mbit/s. But pktlog firmware facility provides per peer tx
statistics. The firmware sends one pktlog event for every four
PPDUs per peer, which include:
* successful number of packets and bytes transmitted
* number of packets and bytes dropped
* retried number of packets and bytes
* rate info per ppdu
Firmware supports WMI_SERVICE_PEER_STATS, pktlog is enabled through
ATH10K_FLAG_PEER_STATS, which is nowadays enabled by default in ath10k.
This patch does not impact throughput.
Tested on QCA9880 with firmware version 10.2.4.70.48. This should also
work with firmware branch 10.2.4-1.0-00029
Parse peer stats from pktlog packets and update the tx rate information
per STA. This way user space can query about transmit rate with iw:
$iw wlan0 station dump
Station 3c:a9:f4:72:bb:a4 (on wlan1)
inactive time: 8210 ms
rx bytes: 9166
rx packets: 44
tx bytes: 1105
tx packets: 9
tx retries: 0
tx failed: 1
rx drop misc: 3
signal: -75 [-75, -87, -88] dBm
signal avg: -75 [-75, -85, -88] dBm
tx bitrate: 39.0 MBit/s MCS 10
rx bitrate: 26.0 MBit/s MCS 3
rx duration: 23250 us
authorized: yes
authenticated: yes
associated: yes
preamble: short
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:100
short preamble: yes
short slot time:yes
connected time: 22 seconds
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
With current NAPI implementation, NAPI poll can deliver more frames
to net core than allotted budget. This may cause warning in napi_poll.
Remaining quota is not accounted, while processing amsdus in
rx_in_ord_ind and rx_ind queue. Adding num_msdus at last can not
prevent delivering more frames to net core. With this change,
all amdus from both in_ord_ind and rx_ind queues are processed and
enqueued into common skb list instead of delivering into mac80211.
Later msdus from common queue are dequeued and delivered depends on
quota availability. This change also simplifies the rx processing in
napi poll routine.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Make sure 16-byte mic is removed from the rx data packet
tail when CCMP-256, GCMP and GCMP-256 ciphers are used
in raw decap mode. This fixed rx traffic failures in those
ciphers in raw mode. Split the helper returning crypto
tail length into two, one to get the ICV length and other
to get the mic lengh for the cipher to make it clean.
Fixes: 2ea9f12cef ("ath10k: add new cipher suite support")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Mostly fixes this time, but also few new features.
Major changes:
wil6210
* remove ssid debugfs file
rsi
* add WOWLAN support for suspend, hibernate and shutdown states
ath10k
* add support for CCMP-256, GCMP and GCMP-256 ciphers on hardware
where it's supported (QCA99x0 and QCA4019)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJZ/HSCAAoJEG4XJFUm622b2sQH+wXgE1swS9xp1AfV3hcVLGoJ
YjLjR3/BAxsIqkYwhswarTDrD3jsOKrL4ywRk+0BAdR7f2BeOYhQXtZqgjvE8cbu
WWv5LmSwuKM6tF3ujgjQ6yZvgyDHl2d7lZL59EWG05K/yjJuU8ByoUhLKM5IiqPh
SWXj3ZtydgGZm2eZTPyan+MFz91jw/X23Jm/AaIAxayf+1J4n1lNpc4rRhUxh/oy
kGLQ2vsVnegSiHJWTboDFPeRha+daBsbf1MQc0Bh7MzDoWcaqSNX5VgrbaRqp35u
sb9pmPZS4FzvAdU3bJ9AIPa9ujjblEvDp1JIhrfBUqiuTdvXDZ7XtW8kVsJk1RY=
=MvWY
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.15
Mostly fixes this time, but also few new features.
Major changes:
wil6210
* remove ssid debugfs file
rsi
* add WOWLAN support for suspend, hibernate and shutdown states
ath10k
* add support for CCMP-256, GCMP and GCMP-256 ciphers on hardware
where it's supported (QCA99x0 and QCA4019)
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Thorsten reported on <fa6e3ee2-91b5-a54b-afe3-87f30aac7a48@leemhuis.info> that
commit c9353bf483 made ath10k unstable with QCA6174 on his Dell XPS13 (9360)
with an error message:
ath10k_pci 0000:3a:00.0: failed to extract amsdu: -11
It only seemed to happen with certain APs, not all, but when it happened the
only way to get ath10k working was to switch the wifi off and on with a hotkey.
As this commit made things even worse (a warning vs breaking the whole
connection) let's revert the commit for now and while the issue is being fixed.
Link: http://lists.infradead.org/pipermail/ath10k/2017-October/010227.html
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.
Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers
in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.
Tested-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In napi_poll, the budget number is used to control the amount of packets
we should handle per poll to balance the resource in the system.
In the list of the amsdu packets reception, we check if there is budget
count left and handle the complete list of the packets, that it will have
chances the very last list will over the budget leftover.
So adding one more parameter - budget_left, this would help while
traversing the list to avoid handling more than the budget given.
Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Fix-suggested-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Link: https://lkml.kernel.org/r/26670dce-4dd2-f8e4-0e14-90d74257e739@virtuozzo.com
Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Each time we get disconnected from AP we get flooded with messages like:
...
ath10k_pci 0000:03:00.0: no channel configured; ignoring frame(s)!
<until ratelimit kicks in>
ath10k_warn: 155 callbacks suppressed
...
Use ath10k_dbg() here too.
Signed-off-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Set the a-mpdu reference number in ath10k to make it accessible in the
receivers radiotap header. Implemented as in ath9k. The reference number is
needed for troubleshooting and research at the receivers site (e.g. to identify
mpdu's that were aggregated in an a-mpdu)
Signed-off-by: Matthias Frei <mf@frei.media>
[kvalo@qca.qualcomm.com: fix checkpatch warning, commit log cleanup]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Report per chain RSSI to mac80211.
Signed-off-by: Norik Dzhandzhapanyan <norikd@gmail.com>
[kvalo@qca.qualcomm.com: fix conflicts and style]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The QCA4019 firmware 10.4-3.2.1-00050 reports only HT MCS rates between
0-9. But 802.11n MCS rates can be larger than that. For example a 2x2
device can send with up to MCS 15.
The firmware encodes the higher MCS rates using the NSS field. The actual
calculation is not documented by QCA but it seems like the NSS field can be
mapped for HT rates to following MCS offsets:
* NSS 1: 0
* NSS 2: 8
* NSS 3: 16
* NSS 4: 24
This offset therefore has to be added for HT rates before they are stored
in the rate_info struct.
Fixes: cec17c3821 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This field will need to be used again for HE, so rename it now.
Again, mostly done with this spatch:
@@
expression status;
@@
-status->vht_nss
+status->nss
@@
expression status;
@@
-status.vht_nss
+status.nss
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix output from checkpatch.pl like:
Block comments use a trailing */ on a separate lin
Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Remove redundant semicolon after switch statement.
Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It's nice to see rt2x00 development has becoming active, for example
adding support for a new chip version. Also wcn36xx has been converted
to use the recently merged QCOM_SMD subsystem. Otherwise new features
and fixes it lots of drivers.
Major changes:
iwlwifi
* some more work in preparation for A000 family support
* add support for radiotap timestamps
* some work on our firmware debugging capabilities
wcn36xx
* convert to a proper QCOM_SMD driver (from the platform_driver interface)
ath10k
* VHT160 support
* dump Copy Engine registers during firmware crash
* search board file extension from SMBIOS
wil6210
* add disable_ap_sme module parameter
rt2x00
* support RT3352 with external PA
* support for RT3352 with 20MHz crystal
* add support for RT5350 WiSoC
brcmfmac
* add support for BCM43455 sdio device
rtl8xxxu
* add support for D-Link DWA-131 rev E1, TP-Link TL-WN822N v4 and others
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYkafBAAoJEG4XJFUm622b0EAH/3mFY0WDfdR/Ych29HX1M/Ao
Bd5gQfKzHS8ANR56qqmxEbpLdBnBa8iNC0IS4RFsWVv6qMoEEOHDLeY5W9XsomWK
i45fQN2XIdjBUOyDXUjsyz006cMe79VzRvFf9gfSekP8i8BCWQzyYC8VKt/F+6Sh
yo9yA4Yv3zA3mA3yRKtxSjLm/6xUXCFVNshKGT0rXc/oEfIN6OnIC1k0p0xw2hhl
GyLN6PSGOqcJc91+IoGOg4TaHzPdWJcWatuxGdQn8gKSDg0+gXaNh9Gtf4H/ojqp
Fwt2Ckk5mgJYk/2TAuFRpRXNMTJznUhp4Tjp2AE7EVM0f5JujUbQuPblOVfLIYk=
=vKKN
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.11
It's nice to see rt2x00 development has becoming active, for example
adding support for a new chip version. Also wcn36xx has been converted
to use the recently merged QCOM_SMD subsystem. Otherwise new features
and fixes it lots of drivers.
Major changes:
iwlwifi
* some more work in preparation for A000 family support
* add support for radiotap timestamps
* some work on our firmware debugging capabilities
wcn36xx
* convert to a proper QCOM_SMD driver (from the platform_driver interface)
ath10k
* VHT160 support
* dump Copy Engine registers during firmware crash
* search board file extension from SMBIOS
wil6210
* add disable_ap_sme module parameter
rt2x00
* support RT3352 with external PA
* support for RT3352 with 20MHz crystal
* add support for RT5350 WiSoC
brcmfmac
* add support for BCM43455 sdio device
rtl8xxxu
* add support for D-Link DWA-131 rev E1, TP-Link TL-WN822N v4 and others
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Not clearing the previous tx bit rate status
results in a ambigous tx bit rate reporting to
mac80211/cfg80211, for example the previous bit
rate status would have been marked as legacy rate
, while the current rate would have been an HT/VHT
rate with the tx bit rate flags set and this results
in exporting tx bitrate as legacy rate but with HT/VHT
rate flags set, fix this by clearing the tx bitrate
status for each event. This also fixes the below
warning when we do:
iw dev wlan#N station dump
WARNING: net/wireless/util.c:1222 cfg80211
[<c022f104>] (warn_slowpath_null) from [<bf3b9adc>]
(cfg80211_calculate_bitrate+0x110/0x1f4 [cfg80211])
[<bf3b9adc>] (cfg80211_calculate_bitrate [cfg80211]) from
[<bf3dcd54>] (nl80211_put_sta_rate+0x44/0x1dc [cfg80211])
[<bf3dcd54>] (nl80211_put_sta_rate [cfg80211]) from
[<bf3cbc34>] (nl80211_set_interface+0x724/0xd70 [cfg80211])
[<bf3cbc34>] (nl80211_set_interface [cfg80211]) from
[<bf3d0a18>] (nl80211_dump_station+0xdc/0x100 [cfg80211])
[<bf3d0a18>] (nl80211_dump_station [cfg80211])
Fixes: cec17c3821 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Tx legacy rate is reported 10 fold, as below
iw dev wlan#N station dump | grep "tx bitrate"
tx bitrate: 240.0 MBit/s
This is because by mistake we multiply by the hardware reported
rate twice by 10, fix this.
Fixes: cec17c3821 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch adds full VHT160 support for QCA9984 chipsets Tested on Netgear
R7800. 80+80 is possible, but disabled so far since it seems to contain
glitches like missing vht station flags (this may be firmware or mac80211
related).
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
[kvalo@qca.qualcomm.com: refactoring and fix few warnings]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The comment on the name indirection suggested an issue but turned out
to be untrue. Digging in older kernel version showed issue with ipw2x00
but that is no longer true so get rid on the name indirection.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.
Parse peer stats and update the tx rate information per STA.
tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
'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: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
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>
In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips,
hw adds padding at the begining of the rx payload to make L3
header 4-byte aligned. In the chips doing this type of padding,
the number of bytes padded will be indicated through msdu_end:info1.
Define a hw_rx_desc_ops wrapper to retrieve the number of padded
bytes and use this while doing undecap. This should fix padding
related issues with ethernt decap format with QCA99X0, QCA9984,
QCA9888 and QCA4019 hw.
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>
Commit 3c97f5de1f ("ath10k: implement NAPI support") conflicts with
ath-current. To avoid any merge problems merge ath-current to ath-next already now.
Conflicts:
drivers/net/wireless/ath/ath10k/htt_rx.c
commit 7a0adc83f3 ("ath10k: improve tx scheduling") is causing
severe throughput drop in multi client mode. This issue is originally
reported in veriwave setup with 50 clients with TCP downlink traffic.
While increasing number of clients, the average throughput drops
gradually. With 50 clients, the combined peak throughput is decreased
to 98 Mbps whereas reverting given commit restored it to 550 Mbps.
Processing txqs for every tx completion is causing overhead. Ideally for
management frame tx completion, pending txqs processing can be avoided.
The change partly reverts the commit "ath10k: improve tx scheduling".
Processing pending txqs after all skbs tx completion will yeild enough
room to burst tx frames.
Fixes: 7a0adc83f3 ("ath10k: improve tx scheduling")
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.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>
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>
It is expected that all pktlog events for 10.4 firmware based solutions
should come through CE8 where as in case of 10.2 firmware based solutions,
it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG).
But from experiments with 10.4 based solutions, it is observed that pktlog
event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event.
Currently, we always parse with 10.2 pktlog header which will lead to
pktlog decoding issues (payload length mismatch exceptions)
For trace points, it is required to provide only the payload size. So
fixing this by simplifying the payload size calculation without the use of
ath10k pktlog headers.
While there, remove the unused ath10k pktlog headers.
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
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:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper channel context")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@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>
commit 5c86d97bcc ("ath10k: combine txrx and replenish task")
introduced deadlock while processing rx in order indication message
for qca6174 based devices. While merging replenish and txrx tasklets,
replenish task should be called out of htt rx ring locking since it
is also try to acquire the same lock.
Unfortunately this issue is not exposed by other solutions (qca988x,
qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
based devices. This patch fixes
=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-wt-ath+ #1353 Tainted: G E
---------------------------------------------
swapper/3/0 is trying to acquire lock:
(&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]
but task is already holding lock:
(&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&htt->rx_ring.lock)->rlock);
lock(&(&htt->rx_ring.lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by swapper/3/0:
#0: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
Fixes: 5c86d97bcc ("ath10k: combine txrx and replenish task")
Reported-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Remove unused inline function phy_mode_to_band.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Legacy rate packets may not necessarily be having a rx status
flag of '0' always, for example management frame have flags
like RX_FLAG_ONLY_MONITOR / RX_FLAG_MACTIME_END also set
Just check 'VHT' and 'HT' flags are not set , and simply clasify it as
legacy rate packets
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
WARN_ON_ONCE when we receive packets for self peer when mac80211
had not assigned a proper channel context. This scenario happens
in QCA4019 when we start the AP via hostapd in background and start
it once again in the background without killing the previous instance!
This happens intermittently when we start / stop hostapd in a while loop
(incase the hostapd is not properly killed). This results in mac80211
chancontext to be unassigned, while the self peer continuous receive
packets in target operating channel. This results in lot of call traces
in the rx path. Make this as a WARN_ON_ONCE to avoid flooding the console
which result in rebooting low memory systems, while still reporting the
warning once that we are receiving packets in target operating channel and
to indicate that something is happening which is not the expected result.
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])
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
