TLV based firmware ex. QCA6174, WCN3990 expects key cipher value
set to 9 while non-TLV firmware expects key cipher value set to 8
for enabling GCMP and GCMP-256 cipher suites.
To fix this problem, attach the key cipher suite values based on
wmi version.
Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath.git patches for 5.1. Major changes:
ath10k
* change QMI interface to support the new (and backwards incompatible)
interface from HL3.1 and used in recent HL2.0 branch firmware releases
ath
* add new country codes for US
The firmware advertises the LDPC support information for HT in
HT capability info in the wmi service ready event. To provide
granularity, firmware now advertises WMI_HT_CAP_RX_LDPC and
WMI_HT_CAP_TX_LDPC separately. To support LDPC, host should
also check for WMI_HT_CAP_RX_LDPC and WMI_HT_CAP_TX_LDPC in HT
capabilities.
Add a condition to existing logic in host to know whether firmware
supports LDPC or not.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1,
WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The management frames transmitted are dma mapped with
direction TO_DEVICE, but incorrectly mapped with
direction FROM_DEVICE during tx complete and error cases.
Fix the direction of dma during dma unmap of the
transmitted management frames.
Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Fixes: 38a1390e02 ("ath10k: dma unmap mgmt tx buffer if wmi cmd send fails")
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.
This change was generated with the following Coccinelle SmPL patch:
@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@
-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
[hch: re-ran the script on the latest tree]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Add wmi configuration cmd to configure base band(BB) power amplifier(PA)
off timing values in hardware. The default PA off timings were fine tuned
to make proper DFS radar detection in QCA reference design. If ODM uses
different PA in their design, then the same default PA off timing values
cannot be used, it requires different settling time to detect radar pulses
very sooner and avoid radar detection problems. In that case it provides
provision to select proper PA off timing values based on the PA hardware used.
The PA component is part of FEM hardware and new device tree entry
"ext-fem-name" is used to indentify the FEM hardware. And this wmi configuration
cmd is enabled via wmi service flag "WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT".
Other way is to apply these values through calibration data, but recalibration
of all boards out there might not be feasible.
This change tested on firmware ver 10.2.4-1.0-00042 in QCA988X chipset.
Signed-off-by: Bhagavathi Perumal S <bperumal@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Memory of tx_stats was allocated when a STA was added. But it's not freed
if the STA failed to be added to driver. This issue could be seen in MDK3
attack case when STA number reached the limit.
Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00005
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Currently in 10.4 FW, all the received 4addr frames are processed for
source port learning which is enabled by default. This learning can't be
disabled by default in FW since it breaks backward compatibility.
Since ath10k uses mac80211 based 4addr mode, source port learning done in
10.4 FW is redundant and also causes issues when 3addr frames are
transmitted/received for a 4addr station.
One such visible functional impact is when GTK rekey frame from
hostapd based AP to 4addr STA is dropped in AP's 10.4 FW. This is since
GTK rekey EAPOL frame is 3addr frame on AP interface and STA enabled
with 4addr is already allowed for receiving 3addr EAPOL frames.
Source port learning implementation in 10.4 FW drops this 3addr GTK rekey
frame in AP destinated for 4addr STA causing disassociation and
re-association for every GTK rekey session. GTK rekey issue is not seen
when learning is disabled in FW.
To prevent such issues without breaking backward compatibility, FW
advertises new service bit making the source port learning configurable and
this learning is being currently disabled during ath10k vdev creation.
* Tested HW: QCA9984
* Tested FW: 10.4-3.6.0.1-00004
Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This issue arise in a race condition between ath10k_sta_state() and
ath10k_htt_fetch_peer_stats(), explained in below scenario
Steps:
1. In ath10k_sta_state(), arsta->tx_stats get deallocated before peer deletion
when the station moves from IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST
state.
2. Meanwhile ath10k receive HTT_T2H_MSG_TYPE_PEER_STATS message.
In ath10k_htt_fetch_peer_stats(), arsta->tx_stats get accessed after
the peer validation check.
Since arsta->tx_stats get freed before the peer deletion [1].
ath10k_htt_fetch_peer_stats() ended up in "use after free" situation.
Fixed this issue by moving the arsta->tx_stats free handling after the
peer deletion. so that ath10k_htt_fetch_peer_stats() will not end up in
"use after free" situation.
Kernel Panic:
Unable to handle kernel NULL pointer dereference at virtual address 00000286
pgd = d8754000
[00000286] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
...
CPU: 0 PID: 6245 Comm: hostapd Not tainted
task: dc44cac0 ti: d4a38000 task.ti: d4a38000
PC is at kmem_cache_alloc+0x7c/0x114
LR is at ath10k_sta_state+0x190/0xd58 [ath10k_core]
pc : [<c02bdc50>] lr : [<bf916b78>] psr: 20000013
sp : d4a39b88 ip : 00000000 fp : 00000001
r10: 00000000 r9 : 1d3bc000 r8 : 00000dc0
r7 : 000080d0 r6 : d4a38000 r5 : dd401b00 r4 : 00000286
r3 : 00000000 r2 : d4a39ba0 r1 : 000080d0 r0 : dd401b00
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5787d Table: 5a75406a DAC: 00000015
Process hostapd (pid: 6245, stack limit = 0xd4a38238)
Stack: (0xd4a39b88 to 0xd4a3a000)
...
[<c02bdc50>] (kmem_cache_alloc) from [<bf916b78>] (ath10k_sta_state+0x190/0xd58 [ath10k_core])
[<bf916b78>] (ath10k_sta_state [ath10k_core]) from [<bf870d4c>] (sta_info_insert_rcu+0x418/0x61c [mac80211])
[<bf870d4c>] (sta_info_insert_rcu [mac80211]) from [<bf88634c>] (ieee80211_add_station+0xf0/0x134 [mac80211])
[<bf88634c>] (ieee80211_add_station [mac80211]) from [<bf83f3c4>] (nl80211_new_station+0x330/0x36c [cfg80211])
[<bf83f3c4>] (nl80211_new_station [cfg80211]) from [<bf6c4040>] (extack_doit+0x2c/0x74 [compat])
[<bf6c4040>] (extack_doit [compat]) from [<c05c285c>] (genl_rcv_msg+0x274/0x30c)
[<c05c285c>] (genl_rcv_msg) from [<c05c1d98>] (netlink_rcv_skb+0x58/0xac)
[<c05c1d98>] (netlink_rcv_skb) from [<c05c25d4>] (genl_rcv+0x20/0x34)
[<c05c25d4>] (genl_rcv) from [<c05c1750>] (netlink_unicast+0x11c/0x204)
[<c05c1750>] (netlink_unicast) from [<c05c1be0>] (netlink_sendmsg+0x30c/0x370)
[<c05c1be0>] (netlink_sendmsg) from [<c0587e90>] (sock_sendmsg+0x70/0x84)
[<c0587e90>] (sock_sendmsg) from [<c058970c>] (___sys_sendmsg.part.3+0x188/0x228)
[<c058970c>] (___sys_sendmsg.part.3) from [<c058a594>] (__sys_sendmsg+0x4c/0x70)
[<c058a594>] (__sys_sendmsg) from [<c0208c80>] (ret_fast_syscall+0x0/0x44)
Code: ebfffec1 e1a04000 ea00001b e5953014 (e7940003)
ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon
Hardware tested: QCA9984
Firmware tested: 10.4-3.6.0.1-00004
Fixes: a904417fc ("ath10k: add extended per sta tx statistics support")
Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_state':
drivers/net/wireless/ath/ath10k/mac.c:6238:7: warning:
variable 'num_tdls_vifs' set but not used [-Wunused-but-set-variable]
'num_tdls_vifs' not used any more after
9a993cc1ea ("ath10k: fix the logic of limiting tdls peer counts")
Also, remove the single called function ath10k_mac_tdls_vifs_count
and ath10k_mac_tdls_vifs_count_iter.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
First set of patches for 4.21. Most notable here is support for
Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide
nvram files for brcmfmac.
Major changes:
brcmfmac
* add support for first trying to get a board specific nvram file
* add support for getting nvram contents from EFI variables
qtnfmac
* use single PCIe driver for all platforms and rename
Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE
* add support for QSR1000/QSR2000 (Topaz) family of chipsets
ath10k
* add support for WCN3990 firmware crash recovery
* add firmware memory dump support for QCA4019
wil6210
* add firmware error recovery while in AP mode
ath9k
* remove experimental notice from dynack feature
iwlwifi
* PCI IDs for some new 9000-series cards
* improve antenna usage on connection problems
* new firmware debugging infrastructure
* some more work on 802.11ax
* improve support for multiple RF modules with 22000 devices
cordic
* move cordic macros and defines to a public header file
* convert brcmsmac and b43 to fully use cordic library
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcATmGAAoJEG4XJFUm622bk9kH/1RWa2z7Gmjr2wBSLHryvRAH
3FAUSJ4GJPH6MJ5X824srkcVsx2Y1RVt2i+bLXRXLq35aZkrFswohTXVM2h5dU7T
Uy2SL+q9pBUcS7fyv9bE7XV7KsFBJly/5p/wciVRZMnEK6X/w6KkBx/vGvlm5I/C
q196KazbVAYcl6s7KMrfFOYt0Wsto/gdEeesSVBkmcCTEkiKUjjJ4WEDVvAKK+qB
AiwgSdioqYmmEiUuredm6bhVqZG3K2mScoCy95N3jXkiDaKkaYgVtBuAU4Cdju/t
WgLIc9EnUYxXZtwnt889X62P1OkDOtKlj/mjdsGyF0Vrs1W+kErDO0NocOvu2Tk=
=9bL7
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2018-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.21
First set of patches for 4.21. Most notable here is support for
Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide
nvram files for brcmfmac.
Major changes:
brcmfmac
* add support for first trying to get a board specific nvram file
* add support for getting nvram contents from EFI variables
qtnfmac
* use single PCIe driver for all platforms and rename
Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE
* add support for QSR1000/QSR2000 (Topaz) family of chipsets
ath10k
* add support for WCN3990 firmware crash recovery
* add firmware memory dump support for QCA4019
wil6210
* add firmware error recovery while in AP mode
ath9k
* remove experimental notice from dynack feature
iwlwifi
* PCI IDs for some new 9000-series cards
* improve antenna usage on connection problems
* new firmware debugging infrastructure
* some more work on 802.11ax
* improve support for multiple RF modules with 22000 devices
cordic
* move cordic macros and defines to a public header file
* convert brcmsmac and b43 to fully use cordic library
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
mac80211 may call us with vif == NULL, if the station is not currently
active (e.g., not associated). It is trivially easy to reproduce a crash
by suspending the system when not connected to an AP:
[ 65.533934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
...
[ 65.574521] pc : ath10k_flush+0x30/0xd0 [ath10k_core]
[ 65.574538] lr : __ieee80211_flush_queues+0x180/0x244 [mac80211]
[ 65.599680] Process kworker/u12:1 (pid: 57, stack limit = 0x(____ptrval____))
[ 65.599682] Call trace:
[ 65.599695] ath10k_flush+0x30/0xd0 [ath10k_core]
[ 65.642064] __ieee80211_flush_queues+0x180/0x244 [mac80211]
[ 65.642079] ieee80211_flush_queues+0x34/0x40 [mac80211]
[ 65.642095] __ieee80211_suspend+0xfc/0x47c [mac80211]
[ 65.658611] ieee80211_suspend+0x30/0x3c [mac80211]
[ 65.658627] wiphy_suspend+0x15c/0x3a8 [cfg80211]
[ 65.672810] dpm_run_callback+0xf0/0x1f0
[ 65.672814] __device_suspend+0x3ac/0x4f8
[ 65.672819] async_suspend+0x34/0xbc
[ 65.684096] async_run_entry_fn+0x54/0x104
[ 65.684099] worker_thread+0x4cc/0x72c
[ 65.684102] kthread+0x134/0x13c
[ 65.684105] ret_from_fork+0x10/0x18
Fixes: 9de4162f09 ("ath10k: add peer flush in ath10k_flush for STATION")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Not all devices using this driver are backed by a PCI device, so it's
not fair to assume 'to_pci_dev()' is valid. Fortunately, we only were
using this to convert straight back to a bare 'device', which means we
were only doing no-op pointer arithmetic, and not actually accessing
potentially out-of-bounds memory. But this is still bad practice.
Just use 'ar->dev' directly, since that's really all we're looking for.
Fixes: 209b2a68de ("ath10k: add platform regulatory domain support")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
I had a couple concerns with this code. First, we definitely need to
set the error code if the kzalloc() fails. Secondly, I was worried that
if we didn't set "arsta->tx_stats" to NULL after freeing it, then it
looks to me like it might lead to a use after free. I can't test that,
but it's harmless to set it to NULL so I did.
Fixes: a904417fc8 ("ath10k: add extended per sta tx statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In the noisy environment, if there are packets in the queue and can't
send out, the suspend timing will be more than 5 seconds due to the wait,
flush the queue to optimize the suspend timing, and let the upper layer to
retry the packets after resume.
Tested with QCA6174 PCI with firmware
WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 PCI.
It's not a regression with new firmware releases.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Adding WMI service check for management tx ack rssi support; this is
done to maintain common avg ack signal in user level for both data
and management tx ack packet.
Tested on QCA4019(fw version-10.4-3.2.1-00063).
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
For WoWLAN support it is expected to support wake up based on discovery of
one or more known SSIDs. This is the WIPHY_WOWLAN_NET_DETECT feature,
which shows up as an NL80211 feature flag.
This shows up in 'iw phy' as:
WoWLAN support:
* wake up on network detection, up to 16 match sets
And it can be enabled with command:
iw phy0 wowlan enable net-detect interval 5000 delay 30 freqs 2412 matches ssid foo
Firmware will do scan by the configured parameters after suspend and
wakeup if it found matched SSIDs. Tested with QCA6174 hw3.0 with
firmware WLAN.RM.4.4.1-00110-QCARMSWPZ-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
[kvalo@codeaurora.org: fix lots of endian bugs, whitespace, commit log and style cleanup]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Currently the wmi command for setting probe request
oui, needed for mac randomization, is sent during
the mac register. At this time, during the driver
init the wmi has already been detached. This can
cause unexpected behavior since the firmware is
already down and the wmi has been detached.
Send the wmi command for setting probe request
oui during the driver start. This will make sure
that the firmware is started and wmi is initialized
before we send this command.
Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Fixes: 60e1d0fb29
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
While using 'ath10k_mac_get_rate_hw_value()' to obtain the hw value
from the passed bitrate, there is a chance of out of bound array access
when wrong bitrate is passed. This is fixed by comparing the bitrates
within the correct size of the ath10k_rates array.
Fixes commit f279294e9e ("ath10k: add support for configuring management
packet rate"). Also correction made to some indents used in the above commit.
Signed-off-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
With the latest firmware design, the beacon interval should be
greater than 100 to bring the multiple vaps.
Set beacon_int_min_gcd to 100, when the wmi service
WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT is enabled
in the firmware. If not, beacon_int_min_gcd will be set
to the default value 1.
Tested in QCA4019 with firmware ver 10.4-3.2.1.1-00015
Tested in QCA9888 with firmware ver 10.4-3.5.1-0005
Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch helps to get the power save state change of each peer
connected to the AP. With WMI_10_4_PEER_STA_PS_STATECHG_EVENTID
event, ps state of each peer is reported to user space via
debugfs.
Use the below command to get the ps state of each sta:
cat /sys/kernel/debug/ieee80211/phyX/netdev::wlanX/stations/
XX:XX:XX:XX:XX:XX/peer_ps_state
If STA is in power save state, we get the peer_ps_state value as 1.
if STA is not in power save state, we get the peer_ps_state value as 0.
If ps_state event is disabled, we get the peer_ps_state value as 2.
We can enable/disable the ps_state events using the debugfs flag
"ps_state_enable"
echo Y > /sys/kernel/debug/ieee80211/phyX/ath10k/ps_state_enable
Y = 1 to enable and Y = 0 to disable
Tested in QCA4019 with firmware ver 10.4-3.2.1.1-00011
Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
By default the firmware uses 1Mbps and 6Mbps rate for management packets
in 2G and 5G bands respectively. But when the user selects different
basic rates from the userspace, we need to send the management
packets at the lowest basic rate selected by the user.
This change makes use of WMI_VDEV_PARAM_MGMT_RATE param for configuring the
management packets rate to the firmware.
Chipsets Tested : QCA988X, QCA9887, QCA9984
FW Tested : 10.2.4-1.0-41, 10.4-3.6.104
Signed-off-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Since commit 9d5804662c ("ath10k: retrieve MAC address from system
firmware if provided"), we support pulling our MAC address from system
firmware. Along with this, we should admit that it's possible for system
firmware to be screwed up as well, omitting the MAC address there.
Provide a fallback, such that we choose a randomly-generated MAC
address, with the local assignment bit set.
This is not a preferred mode of operation and really should only serve
the purpose of keeping the system chugging along while someone figures
out what's wrong with the system. Grepping through other wireless
drivers shows very similar fallback logic though, so why not?
git grep eth_random_addr drivers/net/wireless/
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The vdev-start-response message should cause the
completion to fire, even in the error case. Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.
Add some warning text to print out the invalid status
code to aid debugging, and propagate failure code.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Average ack rssi value is weighted average of ack rssi for
no of msdu's has been sent.
This feature is enabled by the host driver if firmware is capable.
After receiving event from host, firmware allocates the necessary
memory to store the ack_rssi for data packets during the init time.
After each successful transmission, If tx completion status is OK
and 24th bit is set in HTT message header then host will fetch the
ack_rssi else host can ignore the ack_rssi field.
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch adds per station tx statistics support.
Per station tx stats include
- pkts/bytes transmitted at all possible rates(mcs/nss/bw/gi).
- ACK fails count
- ampdu bytes/pkts transmitted at all possible rates(mcs/nss/bw/gi).
- BA fails count
Tested on QCA9984/QCA4019/QCA988x
Firmware: 10.4-3.5.3-00057
10.2.4-1.0-00037
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If there are some tx packets pending in firmware, and then system
enters suspend, firmware will fail for wow enable. This will trigger
mac80211 to stop ath10k and download firmware again, then it is
non-wow suspend.
After add the waiting htt tx complete, then firmware will have some
time window to send or flush the pending tx packets.
Tested with QCA6174 PCI with firmware
WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 PCI.
It's not a regression with new firmware releases.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
the RX and TX path. These filtered channel can in theory still be used by
the hardware but the signal strength is reduced so much that it makes no
sense.
There is already a DT property to limit the available channels but ath10k
has to manually call this functionality to limit the currrently set wiphy
channels further.
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The QCA4019 hw1.0 firmware 10.4-3.2.1-00050 and 10.4-3.5.3-00053 (and most
likely all other) seem to ignore the WMI_CHAN_FLAG_DFS flag during the
scan. This results in transmission (probe requests) on channels which are
not "available" for transmissions.
Since the firmware is closed source and nothing can be done from our side
to fix the problem in it, the driver has to work around this problem. The
WMI_CHAN_FLAG_PASSIVE seems to be interpreted by the firmware to not
scan actively on a channel unless an AP was detected on it. Simple probe
requests will then be transmitted by the STA on the channel.
ath10k must therefore also use this flag when it queues a radar channel for
scanning. This should reduce the chance of an active scan when the channel
might be "unusable" for transmissions.
Fixes: e8a50f8ba4 ("ath10k: introduce DFS implementation")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
These were recently introduced and found by checkpatch:
drivers/net/wireless/ath/ath10k/mac.c:6118: Alignment should match open parenthesis
drivers/net/wireless/ath/ath10k/mac.c:6121: Alignment should match open parenthesis
drivers/net/wireless/ath/ath10k/mac.c:6124: Alignment should match open parenthesis
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Issues a wmi command to firmware when multicast rate change is received with the
new BSS_CHANGED_MCAST_RATE flag. Also fixes the incorrect fixed_rate setting
for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath.git patches for 4.19. Major changes:
wcn36xx
* fix WEP in client mode
wil6210
* add support for Talyn-MB (Talyn ver 2.0) device
* add support for enhanced DMA firmware feature
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJbVgnkAAoJEG4XJFUm622b/DAH/0wmjFQrt1qe/goZ4igZOC5z
TTqPUmv7HO4PbHV6mU5yOFGsRCaGDo1cTyEeoiaYNGH6bQLzzJZeQORkuPQB2q5S
BCwlaET7F2iSmk8hx7eboONyVDm5v2+g6NMHBoikVFz1wZ13kCVa4sHkokUJKYB9
XNw3B2OiarPv9i37DlY3woMlY+6VMQh8J6GiB9cJSa4Xs+7l1aQCdQRP03SabI71
gLBEsW+bEVZrUdJGB5cZ8c6LmukmRQMDKMTQYUna5ZXeW1IX3ejYcQGHzzCZoKJS
LPUmisz4014r5aBzXIu3ctVn4LnVhMS5ms0EH1A6IX3vx8G9QynqH5lm9VQ1OXI=
=kWW/
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.19
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The hardcoded values used in ath10k_mac_tx_push_pending and
ath10k_mac_op_wake_tx_queue set an upper limit of how many packets that
can be consumed from the TX queue.
HTC_HOST_MAX_MSG_PER_TX_BUNDLE is a proper name for this constant, as
the value effectively limits the number of messages that can be consumed
in one step. Thus, the value is an upper limit of the number of messages
that can be added to a TX message bundle.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When running iperf on ath10k SDIO, TX can stop working:
iperf -c 192.168.1.1 -i 1 -t 20 -w 10K
[ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
[ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
[ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
[ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec
[ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 0.0-10.3 sec 9.01 MBytes 7.32 Mbits/sec
There are frames in the ieee80211_txq and there are frames that have
been removed from from this queue, but haven't yet been sent on the wire
(num_pending_tx).
When num_pending_tx reaches max_num_pending_tx, we will stop the queues
by calling ieee80211_stop_queues().
As frames that have previously been sent for transmission
(num_pending_tx) are completed, we will decrease num_pending_tx and wake
the queues by calling ieee80211_wake_queue(). ieee80211_wake_queue()
does not call wake_tx_queue, so we might still have frames in the
queue at this point.
While the queues were stopped, the socket buffer might have filled up,
and in order for user space to write more, we need to free the frames
in the queue, since they are accounted to the socket. In order to free
them, we first need to transmit them.
This problem cannot be reproduced on low-latency devices, e.g. pci,
since they call ath10k_mac_tx_push_pending() from
ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called
on high-latency devices.
Fix the problem by calling ath10k_mac_tx_push_pending(), after
processing rx packets, just like for low-latency devices, also in the
SDIO case. Since we are calling ath10k_mac_tx_push_pending() directly,
we also need to export it.
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In the case of Station connects to AP with narrower bandwidth at beginning.
And later the AP changes the bandwidth to winder bandwidth, the AP will
beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
Since the supported BANDWIDTH will be limited by the PHYMODE, so while
Station receives the bandwidth change request, it will also need to
reconfigure the PHYMODE setting to firmware instead of just configuring
the BANDWIDTH info, otherwise it'll trigger a firmware crash with
non-support bandwidth.
The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
below scenario:
AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
disconnect from AP xxx for new auth to yyy
RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
associated
....
AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz)
....
firmware register dump:
[00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
[04]: 0x00987291 0x00060730 0x00000004 0x00000001
[08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
[12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
[16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
[20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
[24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
[28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
[32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
[36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
[40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
[44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
[48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
[52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
[56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
Tested-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The BIT macro uses unsigned long which some architectures handle as 32 bit
and therefore might cause macro's shift to overflow when used on a value
equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards).
Since 'filled' member in station_info changed to u64, BIT_ULL macro
should be used with all NL80211_STA_INFO_* attribute types instead of BIT
to prevent future possible bugs when one will use BIT macro for higher
attributes by mistake.
This commit cleans up all usages of BIT macro with the above field
in wireless-drivers by changing it to BIT_ULL instead. In addition, there are
some places which don't use BIT nor BIT_ULL macros so align those as well.
Signed-off-by: Omer Efrat <omer.efrat@tandemg.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The India regulatory domain allows CH 173, so add that to the
available channel list. I verified basic connectivity between
a 9880 and 9984 NIC.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.
This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to validate if the host's radar pattern detector unit is
operational and check if the radar information shared by host matches
the radar pulses sent as phy error events from firmware. If the check
fails the firmware won't allow use of DFS channels on AP mode when using
FCC regulatory region.
Hence this patch is mandatory when using a firmware from 10.4-3.6 branch.
Else, DFS channels on FCC regions cannot be used.
Supported Chipsets : QCA9984/QCA9888/QCA4019
Firmware Version : 10.4-3.6-00104
Signed-off-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Configure channel dwell time from duration of the scan request
received from mac80211 when the duration is non-zero. When the
scan request does not have duration value, use the default ones,
the current implementation.
Corresponding flag NL80211_EXT_FEATURE_SET_SCAN_DWELL is
advertized.
Supported Chipsets:
-QCA988X/QCA9887 PCI
-QCA99X0/QCA9984/QCA9888/QCA4019 PCI
-QCA6174/QCA9377 PCI/USB/SDIO
-WCN3990 SNOC
Tested on QCA9984 with firmware ver 10.4-3.6-0010
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath10k_mac_tx_push_txq returns either a postive integer (length) on
success or a negative error code on error.
The "if (ret) break;" statement will thus always break out of the loop
immediately after ath10k_mac_tx_push_txq has returned (making the loop
pointless).
A side effect of this fix is that we will iterate the queue until
ath10k_mac_tx_push_txq returns -ENOENT. This will make sure the queue is
not added back to ar->txqs when it is empty. This could potentially
improve performance somewhat (I have seen a small improvement with SDIO
devices).
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable sta power save in fw for the targets that
supports idle power save. The idle ps enable command
will be ignored by the firmware which does not support
this feature.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The ath10k reports the random_mac_addr capability to upper layer
based on the service bit firmware reported. Driver sets the
spoofed flag in scan_ctrl_flag to firmware if upper layer has
enabled this feature in scan request.
Test with QCA6174 hw3.0 and firmware-6.bin_WLAN.RM.4.4.1-00102-QCARMSWP-1,
but QCA9377 is also affected.
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
These wrappers makes the HTT ops align better with the HIF ops
(where similar wrappers are used).
It also makes it easier for a target to have unsupported ops
(by letting the corresponding function pointer be NULL).
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch fixes regression caused by 0c317a02ca
("cfg80211: support virtual interfaces with different beacon intervals"),
with this change cfg80211 expects the driver to advertize
'beacon_int_min_gcd' to support different beacon intervals in multivap
scenario. This support is added for, QCA988X/QCA99X0/QCA9984/QCA4019.
Verifed AP + mesh bring up on QCA9984 with beacon interval 100msec and
1000msec respectively.
Frimware: firmware-5.bin_10.4-3.5.3-00053
Fixes: 0c317a02ca ("cfg80211: support virtual interfaces with different beacon intervals")
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
For WPA encryption, QCA6174 firmware(version: WLAN.RM.4.4) will unblock
data when M4 was sent successfully. For other encryption which didn't need
4-way handshake firmware will unblock the data when peer authorized. Since
TDLS is 3-way handshake host need send authorize cmd to firmware to unblock
data.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
TDLS peer do not need WEP key. Setting WEP key will lead
to TDLS setup failure. Add fix to avoid setting WEP key
for TDLS peer.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable TDLS peer buffer STA feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA,
it reports this capability through wmi service map in wmi service ready
event. Set related parameter in TDLS WMI command to enable this feature.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When attempt to run worker (ath10k_sta_rc_update_wk) after the station object
(ieee80211_sta) delete will trigger the kernel panic.
This problem arise in AP + Mesh configuration, Where the current node AP VAP
and neighbor node mesh VAP MAC address are same. When the current mesh node
try to establish the mesh link with neighbor node, driver peer creation for
the neighbor mesh node fails due to duplication MAC address. Already the AP
VAP created with same MAC address.
It is caused by the following scenario steps.
Steps:
1. In above condition, ath10k driver sta_state callback (ath10k_sta_state)
fails to do the state change for a station from IEEE80211_STA_NOTEXIST
to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is
called from ieee80211_add_station() to handle the new station
(neighbor mesh node) request from the wpa_supplicant.
2. Concurrently ath10k receive the sta_rc_update callback notification from
the mesh_neighbour_update() to handle the beacon frames of the above
neighbor mesh node. since its atomic callback, ath10k driver queue the
work (ath10k_sta_rc_update_wk) to handle rc update.
3. Due to driver sta_state callback fails (step 1), mac80211 free the station
object.
4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access
the station object which is already deleted. so it will trigger kernel
panic.
Added the peer exist check in sta_rc_update callback before queue the work.
Kernel Panic log:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0204000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1
task: dcef0000 ti: d72b6000 task.ti: d72b6000
PC is at pwq_activate_delayed_work+0x10/0x40
LR is at pwq_activate_delayed_work+0xc/0x40
pc : [<c023f988>] lr : [<c023f984>] psr: 40000193
sp : d72b7f18 ip : 0000007a fp : d72b6000
r10: 00000000 r9 : dd404414 r8 : d8c31998
r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300
r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5787d Table: 595bc06a DAC: 00000015
...
Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238)
Stack: (0xd72b7f18 to 0xd72b8000)
7f00: 00000001 dcee1300
7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089
7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000
7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000
7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340
7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4)
[<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360)
[<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec)
[<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34)
Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs
Rebooting in 3 seconds..
Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
WCN3990 sends mgmt frames by reference via WMI.
The host dma maps the mgmt frame and sends the physical
address to the firmware in the wmi command. Since the
dma mapping is done in the gen_mgmt_tx and if the wmi
command send fails, the corresponding mgmt frame is
not being dma unmapped.
Fix the missing dma unmapping of mgmt tx frame when
wmi command sending fails for mgmt tx by reference
via WMI. The already exisiting mgmt tx using copy by
value does not need such dma unmapping.
Add a separate wmi-tlv op for mgmt tx via ref, which
takes care of unmapping the dma address, in case of
wmi command sending failure.
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable TDLS wider bandwidth support for 5GHz based on firmware wmi capabilities.
This patch is required for chipset QCA9888. Tested with firmware version
10.4-3.5.1-00018.
Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
WCN3990 target uses 64 bit frags_paddr in htt tx descriptor,
which holds the physical address of SKB fragments in tx data path.
In order to support 64 bit bit frags_paddr in htt tx descriptor, define
htt_data_tx_desc_64 descriptor and ath10k_htt_tx_64 method for handling
tx data path with new descriptor fields.
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Due to the limitation of wmi tlv parsing logic, if there are
two parameters in a wmi event with same tlv tag, we can get only
the last value, as it overwrites the prev value of the same tlv tag.
The service ready event in wcn3990 contains two parameters of the
same tag UINT32, due to which the svc bitmap is overwritten with the
DBS support parameter.
Refactor the service ready event parsing to allow parsing two tlv
of the same tag UINT32 for wcn3990.
Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com>
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>
Remove CONFIG_MAC80211_DEBUGFS dependency on ath10k_sta_statistics().
ath10k_sta_statistics() has per sta tx/rx stats and this should not
be dependent on MAC80211_DEBUGFS.
No changes in functionality.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.
This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.
This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.
For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.
Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It is required to update the teardown state of the peer when
a tdls link with that peer is terminated. This information is
useful for the target to perform some cleanups wrt the tdls peer.
Without proper cleanup, target assumes that the peer is connected and
blocks future connection requests, updating the teardown state of the
peer addresses the problem.
Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.
Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Commit 4ca1807815 ("ath10k: disable wake_tx_queue for older devices")
disables the use of the mac80211 TXQs for some devices because of a theoretical
throughput regression. The original regression report[1] was related to
fq_codel qdisc drop performance, which was fixed in commit 9d18562a22
("fq_codel: add batch ability to fq_codel_drop()"). Since then, we have not
seen the TXQ-related regression, so it should be safe to re-enable TXQs.
[1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Do not allow off channel operations like scans/roc when
there are active TDLS sessions.
The Current firmware 10.4-3.5.1-00035 on QCA9888 does not
supports any offchannel operations on active TDLS sessions,
either driver needs to block the offchannel operation requests
or should teardown the TDLS connection.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
To be able to use ath10k_mac_tdls_vif_stations_count() in
ath10k_hw_scan() in the following patch, move the functions
earlier in the file.
This commit is pure code move, no functional changes.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
QCA99x0 and QCA4019 family chips support CCMP-256, GCMP-128, and
GCMP-256 ciphers in hardware, so advertise support for these. As
firmware does not support group management frame ciphers (BIP),
handle them in software (mac80211).
Reviewed-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Currently ath10k host enables power save support in station mode by
default for all firmwares but Power save for station mode still not supported
in some of the firmware versions. Which results in firmware crash while
issueing multiple scan commands.
Fix this problem by introducing new FW feature flag to check power save
support in firmware and then the firmware image can tell to ath10k that power
save mode is not supported in station mode.
Signed-off-by: Venkateswara Naralasetty <vnaralas@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ACPI will rely on device driver to tell it if the device could support
wakeup function when system in D3 state.
This has caused some platform can't support remote wakeup correctly,
because the ACPI wakeup GPE is not enabled, hence registers the .set_wakeup
callback to handle it if device supports wakeup.
Tested with QCA6174 hw3.0, firmware ('WLAN.RM.4.4.1-00008-QCARMSWP-1')
Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch adds the support of TDLS feature for 10.4 firmware
versions.
A new WMI service is added to advertise the support of TDLS for
10.4 firmwares.
Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Fix the following spelling mistakes in messages:
syncronise -> synchronize
unusally -> unusually
addrress -> address
inverval -> interval
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
New features and bug fixes to quite a few different drivers, but
nothing really special standing out.
What makes me happy that we have now more vendors actively
contributing to upstream drivers. In this pull request we have patches
from Broadcom, Intel, Qualcomm, Realtek and Redpine Signals, and I
still have patches from Marvell and Quantenna pending in patchwork. Now
that's something comparing to how things looked 11 years ago in Jeff
Garzik's "State of the Union: Wireless" email:
https://lkml.org/lkml/2006/1/5/671
Major changes:
wil6210
* add low level RF sector interface via nl80211 vendor commands
* add module parameter ftm_mode to load separate firmware for factory
testing
* support devices with different PCIe bar size
* add support for PCIe D3hot in system suspend
* remove ioctl interface which should not be in a wireless driver
ath10k
* go back to using dma_alloc_coherent() for firmware scratch memory
* add per chain RSSI reporting
brcmfmac
* add support multi-scheduled scan
* add scheduled scan support for specified BSSIDs
* add support for brcm43430 revision 0
wlcore
* add wil1285 compatible
rsi
* add RS9113 USB support
iwlwifi
* FW API documentation improvements (for tools and htmldoc)
* continuing work for the new A000 family
* bump the maximum supported FW API to 31
* improve the differentiation between 8000, 9000 and A000 families
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJZT/ROAAoJEG4XJFUm622b/IwH+wQtBXP+P57DZ97BdETcZ3Wd
ejm9KKT3IxcP7kzItT9UR1zv7LNx4NgSkJMfhf37jJ1WIuE2fp/ctNv6mz3PvohW
jD1fLynwEMMC7PLHEy5+xGtL61KYc2mtXs/bfLFl94hZUiaocrsBDIT4fXoyIWif
y3MUlBKDbHA27ULRd485C0MRekRSvR/rq6iST4KsIsa8RflJbdH64teTEnQPp4kh
nvhfnaxVEqHK7mYbarC58yYLNOU8gfQXmeeTfd6jhCXRjfEw37IvtNC8BT4B9ZDX
YMZLbkeDSwNGXIH7EIrpGOYHCPh+qsiJ+sx7YodomcJvd1nVrmbuZZt9/EqWXuY=
=Fd/c
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-06-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.13
New features and bug fixes to quite a few different drivers, but
nothing really special standing out.
What makes me happy that we have now more vendors actively
contributing to upstream drivers. In this pull request we have patches
from Broadcom, Intel, Qualcomm, Realtek and Redpine Signals, and I
still have patches from Marvell and Quantenna pending in patchwork. Now
that's something comparing to how things looked 11 years ago in Jeff
Garzik's "State of the Union: Wireless" email:
https://lkml.org/lkml/2006/1/5/671
Major changes:
wil6210
* add low level RF sector interface via nl80211 vendor commands
* add module parameter ftm_mode to load separate firmware for factory
testing
* support devices with different PCIe bar size
* add support for PCIe D3hot in system suspend
* remove ioctl interface which should not be in a wireless driver
ath10k
* go back to using dma_alloc_coherent() for firmware scratch memory
* add per chain RSSI reporting
brcmfmac
* add support multi-scheduled scan
* add scheduled scan support for specified BSSIDs
* add support for brcm43430 revision 0
wlcore
* add wil1285 compatible
rsi
* add RS9113 USB support
iwlwifi
* FW API documentation improvements (for tools and htmldoc)
* continuing work for the new A000 family
* bump the maximum supported FW API to 31
* improve the differentiation between 8000, 9000 and A000 families
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz.
First, report this to user-space by setting the max-tx-speed
and max-rx-speed vht capabilities.
Second, if the peer rx-speed is configured, and if we
are in 160 or 80+80 mode, and the peer rx-speed matches
the max speed for 2x2 or 1x1 at 160Mhz (long guard interval),
then use that info to set the peer_bw_rxnss_override appropriately.
Without this, a 9984 firmware will not use 2x2 ratesets when
transmitting to peer (it will be stuck at 1x1), because
the firmware would not have configured the rxnss_override.
Signed-off-by: Ben Greear <greearb@candelatech.com>
[sven.eckelmann@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup]
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
[kvalo@qca.qualcomm.com: use hw_params, rename the title]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The ath10k firmware doesn't announce its VHT channel width capabilities in
the vht_cap information from the "service ready event" arguments. The
driver must therefore check whether the 160MHz short GI bit is set and
whether the driver still doesn't set the bits for the 160/80+80 MHz
capabilities.
The two bits for the channel width are a two bit integer and not two
separate bits which cannot be parsed without the knowledge of the other
bit. Using IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ (b10..) as a
mask for this task doesn't make any sense. The correct mask for the VHT
channel width should be used instead to make this check more readable.
Signed-off-by: Ben Greear <greearb@candelatech.com>
[sven.eckelmann@openmesh.com: separate 160Mhz workaround cleanup, add commit
message]
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The original idea is to limit the maximum TDLS peer link, but the logic
is always false, and never be able to restrict the number of TDLS peer
creation.
Fix the logic here and also move the checking earlier, so that it could
avoid to handle the failure case, e.g disable the tdls peer, delete the
peer and also vdev count cleanup.
Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Quite a lot of patches for rtlwifi and iwlwifi this time, but changes
also for other active wireless drivers.
Major changes:
ath9k
* add support for Dell Wireless 1601 PCI device
* add debugfs file to manually override noise floor
ath10k
* bump up FW API to 6 for a new QCA6174 firmware branch
wil6210
* support 8 kB RX buffers
iwlwifi
* work to support A000 devices continues
* add support for FW API 30
* add Geographical and Dynamic Specific Absorption Rate (SAR) support
* support a few new PCI device IDs
rtlwifi
* work on adding Bluetooth coexistance support, not finished yet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJY+cipAAoJEG4XJFUm622b+04H/2u7zhIqv3R5NsmGRlwjKmvd
6us1hcYzUiBW1kBFFtcvokwgqv3Rw/EUi+NYA5UCHgo30HTVJWTqW0q+BUEI7U0X
iwuFdHbs/qjj8hXKgZwaJMVyRhXAbq+iHYaMY5OEDNTRSbxqXA4V69SHGK9vLX0l
KQLJBZX3etnwsyRWrmd4E0roGGfD5tMPpGMUDSlvTPWt0I+1QFUxRI9ohn1fRBpD
p+UHHC+SYF6NzxvfqyPwm6ndb2XOwdAKYljlf4KrBwHtSXvAH8p5EASm4PjGbavY
0mrkv0cb8QOKQNVe9q4B4AmM4iAITZ9i3sQBPJ+EBN2P+kS/lFU5L/+5z3VQjms=
=KTEG
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-04-21' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.12
Quite a lot of patches for rtlwifi and iwlwifi this time, but changes
also for other active wireless drivers.
Major changes:
ath9k
* add support for Dell Wireless 1601 PCI device
* add debugfs file to manually override noise floor
ath10k
* bump up FW API to 6 for a new QCA6174 firmware branch
wil6210
* support 8 kB RX buffers
iwlwifi
* work to support A000 devices continues
* add support for FW API 30
* add Geographical and Dynamic Specific Absorption Rate (SAR) support
* support a few new PCI device IDs
rtlwifi
* work on adding Bluetooth coexistance support, not finished yet
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
* connection quality monitoring with multiple thresholds
* support for FILS shared key authentication offload
* pre-CAC regulatory compliance - only ETSI allows this
* sanity check for some rate confusion that hit ChromeOS
(but nobody else uses it, evidently)
* some documentation updates
* lots of cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEExu3sM/nZ1eRSfR9Ha3t4Rpy0AB0FAlj12HMACgkQa3t4Rpy0
AB0ztBAAi0tH9xR/7iYgChyZV4S8PpYKo2QoQZofG8vzAztboqI4clAxbWEOsJHh
qddjm+foiHVJtZj2LqxjDcaxk69VIh/ERSlR7ve7GCzz9WAAWBMHZop2eArHvgI1
pqP4mQEZ7QISVo88H3LeRdj8NmTwfZYH8u8e2CN3yEpSh1PPrU+slaXRLrjB4uql
XWwwJYQatgDw6Dj4vTIk++DqGo7OhK6CrC1gZLnyOtitTiPzRtfj8rdRHeRKdlj4
wOkUaenjs5r9KsofNYZpzckHp2NEpgIruqCsNdRGHf14EWBC5Q1N35OUOecyQ67T
3VeSnHxU4qjomkXgwqmDKFFOdqtqIruor3YDdO1iwO2TNF+JlNfq5AqUNec/XjUv
VDmj1NRZE0ftJtCkDFm1Q/ABfVDH9i2O6ZBs6a3zb65lA83q1y4xlF48LqDzG3qi
fNnfRO2rOOiyosF3HEkF5u1mfD6MRUtZAc2ZiHckGUpAngs5QOWKqtVgcgWjmbFW
qDTKsFYi2YpGXZAnUjqS4ZtmcgRGEXqg1STJBt4cA8cnmI9Ka5GplACVhqzGeneH
EYMESEct9BOpR6BjABmbZL09NtCkiTPYjiL4V//USr4f6NFhOeHHMYuxYFYIEgC6
ldRjf4EUzZw0QJ8X6L+zxYI5m40fEJ7bGhlIdMo7fWXpRpCaF1Y=
=f4VT
-----END PGP SIGNATURE-----
Merge tag 'mac80211-next-for-davem-2017-04-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
My last pull request has been a while, we now have:
* connection quality monitoring with multiple thresholds
* support for FILS shared key authentication offload
* pre-CAC regulatory compliance - only ETSI allows this
* sanity check for some rate confusion that hit ChromeOS
(but nobody else uses it, evidently)
* some documentation updates
* lots of cleanups
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
It seems set_coverage_class_work is not cancelled anywhere,
though I could not find a crash/warning with this existing
design, its safer to cancel it during stop() and also before
restarting the hardware.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If station advertises diffferent NSS capabilities in Rx_mcs set
of HT and VHT IEs in assoc req, the current NSS computation
logic configures the NSS support only based on Rx_mcs set of
HT capabilities in the driver. This is configuring the station
NSS capabilities incorreclty in the target.
For example, if station advertise Rx_mcs set as 2 spatial streams
in HT capabilities and 1 spatial streams in VHT capabilities in
assoc request, as per current logic we are calculating nss from
HT capabilities and the driver sets peer_num_spatial_streams as
2 for the station which is configured in VHT 1*1.
This patchs fix this issue by calculating the nss from VHT cap if
station supports vht.
Signed-off-by: Venkateswara Rao Naralasetty <c_vnaral@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
I failed to notice that commit 523f6701db ("ath10k: update available channel
list for 5G radio") added two new warnings:
drivers/net/wireless/ath/ath10k/mac.c:3129:6: warning: symbol 'ath10k_mac_update_channel_list' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/mac.c:3170: Alignment should match open parenthesis
Fix those.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If a 5 GHz radio is calibrated for operation in both
the low band (channels 36 to 64) and high band(channels 100 to 169),
hardware allows operations in all the listed channels. However,
if the chip has been calibrated only for the low/high band and
a high/low band channel is configured, due to lack of calibration
there will be potentially invalid signal on those non calibrated channels.
To avoid this problem this patch sets IEEE80211_CHAN_DISABLED flag for
those non calibrated channels by using low_5ghz_chan and high_5ghz_chan
values which we get from target through wmi service ready event.
Driver initialized flags are getting re initialized in handle_channel
in cfg80211. So calling the function to disable the non supported channel
from reg_notifier().
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Doing a channel switch via hostapd_cli seems to update
the new channel context for each VAP's appropriately as below
in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
warning that shows up during this operation and dump the warning only
if no vaps are available for channel switch
hostapd_cli -i wlan0 chan_switch 5 5200
OK
ath10k_pci : mac chanctx switch n_vifs 3 mode 1
ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0
Call Trace:
WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
[<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>]
(ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
[<bf7f150c>] (ath10k_reconfig_complete [ath10k_core])
[<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
[<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
[<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
[<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211])
[<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])
Fixes: d7bf4b4aba ("ath10k: fix ar->rx_channel updating logic")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Set the NL80211_EXT_FEATURE_CQM_RSSI_LIST wiphy extended feature
wholesale in all mac80211-based drivers that do not set the
IEEE80211_VIF_BEACON_FILTER flags on their interfaces. mac80211 will
be processing supplied RSSI values in ieee80211_rx_mgmt_beacon and
will detect when the thresholds set by
ieee80211_set_cqm_rssi_range_config are crossed. Remaining (few)
drivers need code to enable the firmware to monitor the thresholds.
This is mostly only compile-tested.
Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
it adds unnecessary level of indirection, while we just access structure
field
Signed-off-by: Amadeusz Sławiński <amadeusz.slawinski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.
It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.
Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).
This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.
The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.
Signed-off-by: Michal Kazior <michal.kazior@tieto.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>
When adding VHT160 support to ath10k_peer_assoc_h_phymode() the VHT mode
selection code becomes too complex. Simplify it by refactoring the vht part to
a separate function.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Enable advertising support for channel 169, 5Ghz so that
based on the regulatory domain(country code) this channel
shall be active for use. For example in countries like India
this channel shall be available for use with latest regulatory updates
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
'ath10k_mac_tx' does not seems to use the per station table
entry pointer 'sta' (struct ieee80211_sta), hence remove passing
this unused argument
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The txpower is being recalculated when adding interface to make sure
txpower won't overshoot the spec, and when removing the interface,
the txpower should again to be recalculated to restore the correct value
from the active interface list.
Following is one of the scenario
vdev0 is created as STA and connected: txpower:23
vdev1 is created as P2P_DEVICE for control interface: txpower:0
vdev2 is created as p2p go/gc interface: txpower is 21
So the vdev2@txpower:21 will be set to firmware when vdev2 is created.
When we tear down the vdev2, the txpower needs to be recalculated to
re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface.
ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
ath10k_pci mac vdev_id 0 txpower 23
... (adding interface)
ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
ath10k_pci mac vdev_id 2 txpower 21
ath10k_pci mac txpower 21
... (removing interface)
ath10k_pci mac vdev 2 delete (remove interface)
ath10k_pci vdev 1 txpower 0
ath10k_pci vdev 0 txpower 23
ath10k_pci mac txpower 23
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Ath10k reports the phy capability that supports P2P_DEVICE interface.
When we use the P2P supported wpa_supplicant to start connection, it'll
create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
...
ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
And the txpower in per vif bss_conf will only be set to valid tx power when
the interface is assigned with channel_ctx.
But this P2P_DEVICE interface will never be used for any connection, so
that the uninitialized bss_conf.txpower=0 is assinged to the
arvif->txpower when interface created.
Since the txpower configuration is firmware per physical interface.
So the smallest txpower of all vifs will be the one limit the tx power
of the physical device, that causing the low txpower issue on other
active interfaces.
wlan0: Limiting TX power to 21 (24 - 3) dBm
ath10k_pci mac vdev_id 0 txpower 21
ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
ath10k_pci mac txpower 0
This issue only happens when we use the wpa_supplicant that supports
P2P or if we use the iw tool to create the control P2P_DEVICE interface.
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Align it with the cts protection call.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The cts protection vdev parameter, in new QCA9377 TF2.0 firmware,
requires bss peer to be created for the STATION vdev type.
bss peer is being allocated by the firmware after vdev_start/_up commands.
mac80211 may call the cts protection setup at any time, so the
we needs to track the situation and defer the cts configuration
to prevent firmware asserts, like below:
[00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31
[04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000
[08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54
[12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77
[16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
[20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4
[24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2
[28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008
[32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10
[36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC
[40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001
[44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8
[48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001
[52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0
[56]: 0x80911154 0x0040EB28 0x00400000 0x00000000
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Major changes:
rsi
* filter rx frames
* configure tx power
* make it possible to select antenna
* support 802.11d
brcmfmac
* cleanup of scheduled scan code
* support for bcm43341 chipset with different chip id
* support rev6 of PCIe device interface
ath10k
* add spectral scan support for QCA6174 and QCA9377 families
* show used tx bitrate with 10.4 firmware
wil6210
* add power save mode support
* add abort scan functionality
* add support settings retry limit for short frames
bcma
* add Dell Inspiron 3148
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJYQGivAAoJEG4XJFUm622bqG0IAJtSGt4Fxv2jL7GPmPpEUtYK
F6G1PCk9LxO44rOZ15E/CT1vPk6Bnwqp9brdngmXwl7jc+jGs4MQN7g6cD4UZgPm
gxjx8cah2HPRVgEE7PeOILthRxwPA+9klycsvwtglkgQ1SpQVmLHDTLpeOAkRluY
olJGINoGHTD6osud6p3oKK+VP891omJvu8TPqRjhrhLhbQTWAuTxl2Gsdye30yag
CsdaEZb9wdUEBoS80EVRwvgBzqrdKU5kGDGbuzytcyrFrRHo4flti1KgxDg3nIpI
jC4Liwg0yE/aYZlfMqi/960rt8AttCJBDt/vwqp0mOE4IwFsE9Yaio6xXUonAC8=
=a6a/
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2016-12-01' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.10
Major changes:
rsi
* filter rx frames
* configure tx power
* make it possible to select antenna
* support 802.11d
brcmfmac
* cleanup of scheduled scan code
* support for bcm43341 chipset with different chip id
* support rev6 of PCIe device interface
ath10k
* add spectral scan support for QCA6174 and QCA9377 families
* show used tx bitrate with 10.4 firmware
wil6210
* add power save mode support
* add abort scan functionality
* add support settings retry limit for short frames
bcma
* add Dell Inspiron 3148
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
Major changes:
iwlwifi
* finalize and enable dynamic queue allocation
* use dev_coredumpmsg() to prevent locking the driver
* small fix to pass the AID to the FW
* use FW PS decisions with multi-queue
ath9k
* add device tree bindings
* switch to use mac80211 intermediate software queues to reduce
latency and fix bufferbloat
wl18xx
* allow scanning in AP mode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJYOAC4AAoJEG4XJFUm622bUYkH/3SSYp6moSdKpVnVPx7ST7yK
t9WHR9IMZFIhD6vq8AK6+8OQr1TgGjHfPu+WZj7CIl8nu53kcgPRi51gg1mndbNg
9N3RbVp06nGbM2VnW8ZIpg3OLIXatZ4c9g3LFvvtyobYvWGJ6W4D79JdlmTG1ELr
XAjInbxFsgon+CwqCMOaAJx8xYp42rBnPRZZvhOq9O33kRw8Umo9UQw0s1U2Vfgx
prxQ6d0GxNAPEe8QiDw/vtBcXWFMOhQeDl8sK70ZcojSn1FY730NsIh/Y86PcQTK
6TsvOL5gg+rd0ln8TZRAslnDrZBAhTEDqUzLQMRJ9VjEj5RFd8eLCSIzHfaroI8=
=4qCH
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2016-11-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.10
Major changes:
iwlwifi
* finalize and enable dynamic queue allocation
* use dev_coredumpmsg() to prevent locking the driver
* small fix to pass the AID to the FW
* use FW PS decisions with multi-queue
ath9k
* add device tree bindings
* switch to use mac80211 intermediate software queues to reduce
latency and fix bufferbloat
wl18xx
* allow scanning in AP mode
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
Neither of these did the right thing:
- get_tsf just returned 0
- set_tsf assumed a simple offset was applied against
get_tsf(), which works, except in the case of
calculating TSF from rx_mactime (actual TSF).
Just remove them for now. We can reimplement set_tsf in
terms of TSF increment/decrement in the future if get_tsf
is ever supported by FW.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Current set_tsf is implemented in terms of TSF_INCREMENT
only. Instead support new WMI command TSF_DECREMENT and
export these through offset_tsf. Advantage is we get
more accurate TSF adjustments, and don't calculate wrong
offset in case absolute TSF was calculated from rx_mactime
(actual TSF).
The new WMI command is available in firmware
10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
firmware or vice versa shouldn't be a problem since
get/set tsf logic was already broken.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Indicate hardware (or firmware) supports that CQM packet-loss report
will be generated based on station kickout algorithm. As of now mac80211
tracks connection loss by missing msdu counts (50) whereas ath10k
firmware tracks them by missing ppdus (+ BAR tries). While firmware is
trying to adapt its rate table, mac80211 might send out low_ack event to
hostapd. This is causing frequent connect and disconnect iteration under
noisy environment or when station is roaming around.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This partially reverts 'commit 2cdce425aa
("ath10k: Fix broken NULL func data frame status for 10.4")'
Unfortunately this breaks sending NULL func and the existing
issue of obtaining proper tx status for NULL function will be
fixed. Also update the comments for feature flag added to be
useless and not working
Fixes: 2cdce425aa "ath10k: Fix broken NULL func data frame status for
10.4"
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
