summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath10k/mac.c
AgeCommit message (Collapse)Author
2017-12-27ath10k: update copyright yearKalle Valo
Update year for Qualcomm Atheros, Inc. copyrights. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-27ath10k: advertise TDLS wider bandwidth support for 5GHzBalaji Pothunoori
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>
2017-12-27ath10k: Add support for htt_data_tx_desc_64 descriptorGovind Singh
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>
2017-12-14ath10k: wmi: modify svc bitmap parsing for wcn3990Rakesh Pillai
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>
2017-12-14ath10k: add per peer tx stats support for 10.2.4Anilkumar Kolli
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>
2017-12-14ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statisticsAnilkumar Kolli
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>
2017-12-14ath10k: handling qos at STA side based on AP WMM enable/disableBalaji Pothunoori
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>
2017-12-02ath10k: update tdls teardown state to targetManikanta Pubbisetty
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>
2017-12-02ath10k: re-enable TXQs for all devicesToke Høiland-Jørgensen
Commit 4ca1807815aa ("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 9d18562a2278 ("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>
2017-10-27ath10k: block offchannel operations if TDLS session is activeAnilkumar Kolli
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>
2017-10-27ath10k: move ath10k_mac_tdls_vif*() functionsAnilkumar Kolli
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>
2017-10-13ath10k: add new cipher suite supportRajkumar Manoharan
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>
2017-10-13ath10k: check power save support in STA mode through FW IEVenkateswara Naralasetty
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>
2017-08-31ath10k: configure and enable the wakeup capabilityRyan Hsu
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>
2017-08-03ath10k: add tdls support for 10.4 firmwaresManikanta Pubbisetty
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>
2017-06-28ath10k: fix a bunch of spelling mistakes in messagesColin Ian King
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>
2017-06-25Merge tag 'wireless-drivers-next-for-davem-2017-06-25' of ↵David S. Miller
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>
2017-06-21ath10k: configure rxnss_override for QCA9984Ben Greear
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>
2017-06-21ath10k: use complete VHT chan width for 160MHz workaroundBen Greear
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>
2017-06-16networking: introduce and use skb_put_data()Johannes Berg
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>
2017-06-01ath10k: fix the logic of limiting tdls peer countsRyan Hsu
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>
2017-04-24Merge tag 'wireless-drivers-next-for-davem-2017-04-21' of ↵David S. Miller
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>
2017-04-20Merge tag 'mac80211-next-for-davem-2017-04-18' of ↵David S. Miller
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>
2017-04-05ath10k: fix block comments styleMarcin Rokicki
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>
2017-04-05ath10k: cancel coverage class work during stop and restartMohammed Shafi Shajakhan
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>
2017-04-05ath10k: fix station nss computationVenkateswara Rao Naralasetty
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>
2017-03-20ath10k: fix warnings from an earlier commitKalle Valo
I failed to notice that commit 523f6701dbab ("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>
2017-03-16ath10k: update available channel list for 5G radioTamizh chelvam
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>
2017-03-09ath10k: fix a warning during channel switch with multiple vapsMohammed Shafi Shajakhan
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: d7bf4b4aba05 ("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>
2017-03-06wireless: Set NL80211_EXT_FEATURE_CQM_RSSI_LIST in multiple driversAndrew Zaborowski
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>
2017-02-14ath10k: remove ath10k_vif_to_arvif()Amadeusz Sławiński
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>
2017-01-19ath10k: prevent sta pointer rcu violationMichal Kazior
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>
2017-01-13ath10k: add VHT160 supportSebastian Gottschall
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>
2017-01-13ath10k: refactor ath10k_peer_assoc_h_phymode()Kalle Valo
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>
2016-12-30ath10k: enable advertising support for channel 169, 5GhzMohammed Shafi Shajakhan
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>
2016-12-30ath10k: Remove passing unused argument for ath10k_mac_txMohammed Shafi Shajakhan
'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>
2016-12-30ath10k: recal the txpower when removing interfaceRyan Hsu
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>
2016-12-30ath10k: fix incorrect txpower set by P2P_DEVICE interfaceRyan Hsu
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>
2016-12-29ath10k: add debug trace to rts/cts set functionBartosz Markowski
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>
2016-12-29ath10k: set CTS protection VDEV param only if VDEV is upBartosz Markowski
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>
2016-12-02Merge tag 'wireless-drivers-next-for-davem-2016-12-01' of ↵David S. Miller
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>
2016-12-01ath10k: fix soft lockup during firmware crash/hw-restartMohammed Shafi Shajakhan
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: 3c97f5de1f28 ("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>
2016-11-27Merge tag 'wireless-drivers-next-for-davem-2016-11-25' of ↵David S. Miller
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>
2016-11-23ath10k: fix monitor vdev for receiving other bss framesManoharan, Rajkumar
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>
2016-11-23ath10k: remove set/get_tsf ieee80211_opsPedersen, Thomas
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>
2016-11-23ath10k: implement offset_tsf ieee80211_opPedersen, Thomas
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>
2016-11-23ath10k: advertize hardware packet loss mechanismRajkumar Manoharan
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>
2016-11-15ath10k: fix failure to send NULL func frame for 10.4Mohammed Shafi Shajakhan
This partially reverts 'commit 2cdce425aa33 ("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: 2cdce425aa33 "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>
2016-10-19mac80211: add a HW flag for supporting HW TX fragmentationSara Sharon
Currently mac80211 determines whether HW does fragmentation by checking whether the set_frag_threshold callback is set or not. However, some drivers may want to set the HW fragmentation capability depending on HW generation. Allow this by checking a HW flag instead of checking the callback. Signed-off-by: Sara Sharon <sara.sharon@intel.com> [added the flag to ath10k and wlcore] Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-10-13ath10k: fix kernel panic due to race in accessing arvif listVasanthakumar Thiagarajan
arvifs list is traversed within data_lock spin_lock in tasklet context to fill channel information from the corresponding vif. This means any access to arvifs list for add/del operations should also be protected with the same spin_lock to avoid the race. Fix this by performing list add/del on arvfis within the data_lock. This could fix kernel panic something like the below. LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core] PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core]) [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core]) [<c00312d4>] (tasklet_action+0x8c/0xec) [<c00309a8>] (__do_softirq+0xdc/0x208) [<c0030d6c>] (irq_exit+0x84/0xe0) [<c005db04>] (__handle_domain_irq+0x80/0xa0) [<c00085c4>] (gic_handle_irq+0x38/0x5c) [<c0009640>] (__irq_svc+0x40/0x74) (gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0) 0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769) 764 struct cfg80211_chan_def def; 765 766 lockdep_assert_held(&ar->data_lock); 767 768 list_for_each_entry(arvif, &ar->arvifs, list) { 769 if (arvif->vdev_id == vdev_id && 770 ath10k_mac_vif_chan(arvif->vif, &def) == 0) 771 return def.chan; 772 } 773 Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
generated by cgit (git 2.34.1) at 2024-06-02 12:04:54 +0000