summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath10k/wmi.c
AgeCommit message (Collapse)Author
2018-10-01ath10k: add debugfs support to get power save state change of STAMaharaja Kennadyrajan
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>
2018-10-01ath10k: fix tx status flag setting for management framesRakesh Pillai
The tx_status for management frames is being filled incorrectly in the flags of skb_cb. This incorrect flag setting causes the upper layers to consider that the particular frame was not transmitted properly, leading to improper behavior. Set the IEEE80211_TX_STAT_ACK flag in the info flags of skb_cb, to indicate the successful transmission of the management frame. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: dc405152bb64d4ae01c9ac669de25b2d1fb6fc2d Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-01ath10k: fix vdev-start timeout on errorBen Greear
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>
2018-09-06ath10k: wmi: disable softirq's while calling ieee80211_rxErik Stromdahl
This is done in order not to trig the below warning in ieee80211_rx_napi: WARN_ON_ONCE(softirq_count() == 0); ieee80211_rx_napi requires that softirq's are disabled during execution. The High latency bus drivers (SDIO and USB) sometimes call the wmi ep_rx_complete callback from non softirq context, resulting in a trigger of the above warning. Calling ieee80211_rx_ni with softirq's already disabled (e.g., from softirq context) should be safe as the local_bh_disable and local_bh_enable functions (called from ieee80211_rx_ni) are fully reentrant. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-06ath10k: avoid possible memory access violationK.T.VIJAYAKUMAAR
array "ctl_power_table" access index "pream" is initialized with -1 and is raised as a static analysis tool issue. [drivers\net\wireless\ath\ath10k\wmi.c:4719] -> [drivers\net\wireless\ath\ath10k\wmi.c:4730]: (error) Array index -1 is out of bounds. Since the "pream" index for accessing ctl_power_table array is initialized with -1, there is a chance of memory access violation for the cases below. 1) wmi_pdev_tpc_final_table_event change frequency is between 2483 and 5180 2) pream_idx is out of the enumeration ranges of wmi_tpc_pream_2ghz, wmi_tpc_pream_5ghz Signed-off-by: K.T.VIJAYAKUMAAR <vijay.bvb@samsung.com> [kvalo@codeaurora.org: clean up the warning message] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-03ath10k: retrieve MAC address from system firmware if providedBrian Norris
Devices may provide their own MAC address via system firmware (e.g., device tree), especially in the case where the device doesn't have a useful EEPROM on which to store its MAC address (e.g., for integrated Wifi). Use the generic device helper to retrieve the MAC address, and (if present) honor it above the MAC address advertised by the card. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-28ath10k: schedule hardware restart if WMI command times outMartin Willi
When running in AP mode, ath10k sometimes suffers from TX credit starvation. The issue is hard to reproduce and shows up once in a few days, but has been repeatedly seen with QCA9882 and a large range of firmwares, including 10.2.4.70.67. Once the module is in this state, TX credits are never replenished, which results in "SWBA overrun" errors, as no beacons can be sent. Even worse, WMI commands run in a timeout while holding the conf mutex for three seconds each, making any further operations slow and the whole system unresponsive. The firmware/driver never recovers from that state automatically, and triggering TX flush or warm restarts won't work over WMI. So issue a hardware restart if a WMI command times out due to missing TX credits. This implies a connectivity outage of about 1.4s in AP mode, but brings back the interface and the whole system to a usable state. WMI command timeouts have not been seen in absent of this specific issue, so taking such drastic actions seems legitimate. Signed-off-by: Martin Willi <martin@strongswan.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-30ath10k: add debugfs file warm_hw_resetMaharaja Kennadyrajan
Debugfs support to do hardware warm reset with WMI command WMI_PDEV_PARAM_PDEV_RESET for 10.4 and 10.2.4(if wmi service is enabled in the firmware for backward compatibility). This change is purely for debugging purpose when hardware hangs/mutes. This hardware reset won't affect the connectivity but there will be small pause in data traffic. Here we are doing BB/MAC level reset and hence whenever the BB/MAC watchdog is triggered, it does a hardware_chip_reset. So the target will be in the active state. Below command used to warm reset the hardware. echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/warm_hw_reset Tested in QCA988X with firmware ver 10.2.4.70.45 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>
2018-07-30ath10k: handle mgmt tx completion eventRakesh Pillai
WCN3990 transmits management frames via WMI with reference. Currently, with the management tx completion not being handled, these frames are not getting freed even after the transmission status is returned by the firmware. The transmitted management frames should be freed when the firmware sends the over-the-air tx status of the corresponding management frames. Handle the wmi mgmt tx completion event and free the corresponding management frame. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-14ath10k: use dma_zalloc_coherent instead of allocator/memsetYueHaibing
Use dma_zalloc_coherent instead of dma_alloc_coherent followed by memset 0. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-14ath10k: support use of channel 173Ben Greear
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>
2018-06-13ath10k: fix memory leak of tpc_statsColin Ian King
Currently tpc_stats is allocated and is leaked on the return path if num_tx_chain is greater than WMI_TPC_TX_N_CHAIN. Avoid this leak by performing the check on num_tx_chain before the allocation of tpc_stats. Detected by CoverityScan, CID#1469422 ("Resource Leak") Fixes: 4b190675ad06 ("ath10k: fix kernel panic while reading tpc_stats") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-25ath10k: DFS Host ConfirmationSriram R
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>
2018-05-25ath: add support to get the detected radar specificationsSriram R
This enables ath10k/ath9k drivers to collect the specifications of the radar type once it is detected by the dfs pattern detector unit. Usage of the collected info is specific to driver implementation. For example, collected radar info could be used by the host driver to send to co-processors for additional processing/validation. Note: 'radar_detector_specs' data containing the specifications of different radar types which was private within dfs_pattern_detector/ dfs_pri_detector is now shared with drivers as well for making use of this information. Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-12ath10k: remove variables which set but not usedKenneth Lu
Variable buf_len and num_vdev_stats are being assigned but never read. These are redundant and can be remove. Signed-off-by: Kenneth Lu <kuohsianglu@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-27ath10k: fix spelling mistake: "servive" -> "service"Colin Ian King
Trivial fix to spelling mistake in ath10k_warn warning message text Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-27ath10k: fix kernel panic while reading tpc_statsTamizh Chelvam
When attempt to read tpc_stats for the chipsets which support more than 3 tx chain will trigger kernel panic(kernel stack is corrupted) due to writing values on rate_code array out of range. This patch changes the array size depends on the WMI_TPC_TX_N_CHAIN and added check to avoid write values on the array if the num tx chain get in tpc config event is greater than WMI_TPC_TX_N_CHAIN. Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00057 Kernel panic log : [ 323.510944] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: bf90c654 [ 323.510944] [ 323.524390] CPU: 0 PID: 1908 Comm: cat Not tainted 3.14.77 #31 [ 323.530224] [<c021db48>] (unwind_backtrace) from [<c021ac08>] (show_stack+0x10/0x14) [ 323.537941] [<c021ac08>] (show_stack) from [<c03c53c0>] (dump_stack+0x80/0xa0) [ 323.545146] [<c03c53c0>] (dump_stack) from [<c022e4ac>] (panic+0x84/0x1e4) [ 323.552000] [<c022e4ac>] (panic) from [<c022e61c>] (__stack_chk_fail+0x10/0x14) [ 323.559350] [<c022e61c>] (__stack_chk_fail) from [<bf90c654>] (ath10k_wmi_event_pdev_tpc_config+0x424/0x438 [ath10k_core]) [ 323.570471] [<bf90c654>] (ath10k_wmi_event_pdev_tpc_config [ath10k_core]) from [<bf90d800>] (ath10k_wmi_10_4_op_rx+0x2f0/0x39c [ath10k_core]) [ 323.583047] [<bf90d800>] (ath10k_wmi_10_4_op_rx [ath10k_core]) from [<bf8fcc18>] (ath10k_htc_rx_completion_handler+0x170/0x1a0 [ath10k_core]) [ 323.595702] [<bf8fcc18>] (ath10k_htc_rx_completion_handler [ath10k_core]) from [<bf961f44>] (ath10k_pci_hif_send_complete_check+0x1f0/0x220 [ath10k_pci]) [ 323.609421] [<bf961f44>] (ath10k_pci_hif_send_complete_check [ath10k_pci]) from [<bf96562c>] (ath10k_ce_per_engine_service+0x74/0xc4 [ath10k_pci]) [ 323.622490] [<bf96562c>] (ath10k_ce_per_engine_service [ath10k_pci]) from [<bf9656f0>] (ath10k_ce_per_engine_service_any+0x74/0x80 [ath10k_pci]) [ 323.635423] [<bf9656f0>] (ath10k_ce_per_engine_service_any [ath10k_pci]) from [<bf96365c>] (ath10k_pci_napi_poll+0x44/0xe8 [ath10k_pci]) [ 323.647665] [<bf96365c>] (ath10k_pci_napi_poll [ath10k_pci]) from [<c0599994>] (net_rx_action+0xac/0x160) [ 323.657208] [<c0599994>] (net_rx_action) from [<c02324a4>] (__do_softirq+0x104/0x294) [ 323.665017] [<c02324a4>] (__do_softirq) from [<c0232920>] (irq_exit+0x9c/0x11c) [ 323.672314] [<c0232920>] (irq_exit) from [<c0217fc0>] (handle_IRQ+0x6c/0x90) [ 323.679341] [<c0217fc0>] (handle_IRQ) from [<c02084e0>] (gic_handle_irq+0x3c/0x60) [ 323.686893] [<c02084e0>] (gic_handle_irq) from [<c02095c0>] (__irq_svc+0x40/0x70) [ 323.694349] Exception stack(0xdd489c58 to 0xdd489ca0) [ 323.699384] 9c40: 00000000 a0000013 [ 323.707547] 9c60: 00000000 dc4bce40 60000013 ddc1d800 dd488000 00000990 00000000 c085c800 [ 323.715707] 9c80: 00000000 dd489d44 0000092d dd489ca0 c026e664 c026e668 60000013 ffffffff [ 323.723877] [<c02095c0>] (__irq_svc) from [<c026e668>] (rcu_note_context_switch+0x170/0x184) [ 323.732298] [<c026e668>] (rcu_note_context_switch) from [<c020e928>] (__schedule+0x50/0x4d4) [ 323.740716] [<c020e928>] (__schedule) from [<c020e490>] (schedule_timeout+0x148/0x178) [ 323.748611] [<c020e490>] (schedule_timeout) from [<c020f804>] (wait_for_common+0x114/0x154) [ 323.756972] [<c020f804>] (wait_for_common) from [<bf8f6ef0>] (ath10k_tpc_stats_open+0xc8/0x340 [ath10k_core]) [ 323.766873] [<bf8f6ef0>] (ath10k_tpc_stats_open [ath10k_core]) from [<c02bb598>] (do_dentry_open+0x1ac/0x274) [ 323.776741] [<c02bb598>] (do_dentry_open) from [<c02c838c>] (do_last+0x8c0/0xb08) [ 323.784201] [<c02c838c>] (do_last) from [<c02c87e4>] (path_openat+0x210/0x598) [ 323.791408] [<c02c87e4>] (path_openat) from [<c02c9d1c>] (do_filp_open+0x2c/0x78) [ 323.798873] [<c02c9d1c>] (do_filp_open) from [<c02bc85c>] (do_sys_open+0x114/0x1b4) [ 323.806509] [<c02bc85c>] (do_sys_open) from [<c0208c80>] (ret_fast_syscall+0x0/0x44) [ 323.814241] CPU1: stopping [ 323.816927] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.77 #31 [ 323.823008] [<c021db48>] (unwind_backtrace) from [<c021ac08>] (show_stack+0x10/0x14) [ 323.830731] [<c021ac08>] (show_stack) from [<c03c53c0>] (dump_stack+0x80/0xa0) [ 323.837934] [<c03c53c0>] (dump_stack) from [<c021cfac>] (handle_IPI+0xb8/0x140) [ 323.845224] [<c021cfac>] (handle_IPI) from [<c02084fc>] (gic_handle_irq+0x58/0x60) [ 323.852774] [<c02084fc>] (gic_handle_irq) from [<c02095c0>] (__irq_svc+0x40/0x70) [ 323.860233] Exception stack(0xdd499fa0 to 0xdd499fe8) [ 323.865273] 9fa0: ffffffed 00000000 1d3c9000 00000000 dd498000 dd498030 10c0387d c08b62c8 [ 323.873432] 9fc0: 4220406a 512f04d0 00000000 00000000 00000001 dd499fe8 c021838c c0218390 [ 323.881588] 9fe0: 60000013 ffffffff [ 323.885070] [<c02095c0>] (__irq_svc) from [<c0218390>] (arch_cpu_idle+0x30/0x50) [ 323.892454] [<c0218390>] (arch_cpu_idle) from [<c026500c>] (cpu_startup_entry+0xa4/0x108) [ 323.900690] [<c026500c>] (cpu_startup_entry) from [<422085a4>] (0x422085a4) Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-24ath10k: support MAC address randomization in scanCarl Huang
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>
2018-04-24ath10k: add WMI_SERVICE_AVAILABLE_EVENT supportCarl Huang
Add WMI_SERVICE_AVAILABLE_EVENT to extend WMI_SERVICE_READY_EVENT, the 128bit service map in WMI_SERVICE_READY_EVENT is not enough for firmware to notice new WLAN service to host driver. Hereby, for thoese new WLAN service, firmware will notice host driver by WMI_SERVICE_AVAILABLE_EVENT. Signed-off-by: Alan Liu <alanliu@codeaurora.org> Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-19ath10k: fix a typo in ath10k_wmi_set_wmm_param()Maharaja Kennadyrajan
Fix a typo in the function ath10k_wmi_set_wmm_param(). Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-10ath10k: fix spelling mistake: "tiggers" -> "triggers"Colin Ian King
Trivial fix to spelling mistake in message text Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-10ath10k: avoid possible string overflowArnd Bergmann
The way that 'strncat' is used here raised a warning in gcc-8: drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables': drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] Effectively, this is simply a strcat() but the use of strncat() suggests some form of overflow check. Regardless of whether this might actually overflow, using strlcat() instead of strncat() avoids the warning and makes the code more robust. Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29ath10k: fix vdev stats for 10.4 firmwareRajkumar Manoharan
Currently vdev stats displayed in fw_stats are applicable only for TLV based firmware and fix it for 10.4 firmware as of now. The vdev stats in 10.4 firmware is split into two parts (vdev_stats, vdev_stats_extended). The actual stats are captured only in extended vdev stats. In order to enable vdev stats, appropriate feature bit will be set on extended resource config. As FTM related counters are available only on newer 10.4 based firmware, these counters will be displayed only on valid data. Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29ath10k: suppress "Unknown eventid: 36925" warningsSathishkumar Muruganandam
FW has Smart Logging feature enabled by default for detecting failures and processing FATAL_CONDITION_EVENTID (36925 - 0x903D) back to host. Since ath10k doesn't implement the Smart Logging and FATAL CONDITION EVENT processing yet, suppressing the unknown event ID warning by moving this under ATH10K_DBG_WMI. Simulated the same issue by having associated STA powered off when ping flood was running from AP backbone. This triggerd STA KICKOUT in AP followed by FATAL CONDITION event 36925. Issue was reproduced and verified in below DUT ------------------------------------------------ AP mode of OpenWRT QCA9984 running 6.0.8 with FW ver 10.4-3.5.3-00053 Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-26ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowaitCarl Huang
The skb may be freed in tx completion context before trace_ath10k_wmi_cmd is called. This can be easily captured when KASAN(Kernel Address Sanitizer) is enabled. The fix is to move trace_ath10k_wmi_cmd before the send operation. As the ret has no meaning in trace_ath10k_wmi_cmd then, so remove this parameter too. Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-26ath10k: debugfs support to get final TPC stats for 10.4 variantsMaharaja Kennadyrajan
Export the final Transmit Power Control (TPC) value, which is the minimum of control power and existing TPC value to user space via a new debugfs file "tpc_stats_final" to help with debugging. It works with the new wmi cmd and event introduced in 10.4 firmware branch. WMI command ID: WMI_PDEV_GET_TPC_TABLE_CMDID WMI event ID: WMI_PDEV_TPC_TABLE_EVENTID cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats_final $ cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats_final TPC config for channel 5180 mode 10 CTL = 0x 0 Reg. Domain = 58 Antenna Gain = 0 Reg. Max Antenna Gain = 0 Power Limit = 60 Reg. Max Power = 60 Num tx chains = 2 Num supported rates = 109 ******************* CDD POWER TABLE **************** No. Preamble Rate_code tpc_value1 tpc_value2 tpc_value3 0 CCK 0x40 0 0 1 CCK 0x41 0 0 [...] 107 HTCUP 0x 0 46 46 108 HTCUP 0x 0 46 46 ******************* STBC POWER TABLE **************** No. Preamble Rate_code tpc_value1 tpc_value2 tpc_value3 0 CCK 0x40 0 0 1 CCK 0x41 0 0 [...] 107 HTCUP 0x 0 46 46 108 HTCUP 0x 0 46 46 *********************************** TXBF not supported ********************************** The existing tpc_stats debugfs file provides the dump which is minimum of target power and regulatory domain. cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats Hardware_used: QCA4019 Firmware version: firmware-5.bin_10.4-3.0-00209 Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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-02ath10k: handle tdls peer eventsManikanta Pubbisetty
Handle tdls peer events from the target. TDLS events for the peer could be discover, teardown, etc. As of now, adding the logic to handle tdls teardown events alone. Teardown due to peer traffic indication(PTR) timeout is one such teardown event from the target. 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-10-27ath10k: fix sending wmi cmd during the tdls teardownAnilkumar Kolli
The current firmware 10.4-3.5.1-00035 on QCA9888 supports TDLS explicit mode, it expects WMI_TDLS_ENABLE_PASSIVE for tdls setup and WMI_TDLS_DISABLE for tdls teardown. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-08-03ath10k: push peer type to target for TDLS peersManikanta Pubbisetty
WMI interface for all the firmwares(except QCA6174) does not include the type of peer(default/bss/tdls) requested during peer creation, therefore target creates a default peer. TDLS implementation on 10.4 firmware requires host to configure the peer type(tdls) for TDLS peers. This patch adds peer type parameter to the existing WMI interface for peer creation to accommodate this requirement. Tested this change on QCA9888(10.4-3.5.1-00018) and QCA988x(10.2.4.70.9-2) with ping tests for AP/STA modes. Signed-off-by: Manikanta Pubbisetty <mpubbise@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-07-06ath10k: fix indenting in ath10k_wmi_update_noa()Kalle Valo
Commit 59ae1d127ac0 ("networking: introduce and use skb_put_data()") introduced a new checkpatch warning: drivers/net/wireless/ath/ath10k/wmi.c:3308: code indent should use tabs where possible Fix that. 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-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-05-31ath10k: go back to using dma_alloc_coherent() for firmware scratch memoryAdrian Chadd
This reverts commit b057886524be ("ath10k: do not use coherent memory for allocated device memory chunks") in 2015 which converted this allocation from dma_map_coherent() to kzalloc() / dma_map_single(). The current problem manifests when using later model NICs with larger (>700KiB) scratch spaces in memory. Although the kzalloc call succeeds, the software IOMMU TLB code (via dma_map_single()) panics because it can't find 700KiB of linear physmem bounce buffers for DMA. Now, this is a bit of a silly failure mode for the dma map API, but it's what we currently have to play with. In these cases, doing kzalloc() works fine, but the dma_map_single() call fails. After chatting with Linus briefly about this, it indeed should be using dma_alloc_coherent() for doing larger device memory allocation that requires some kind of physical address mapping. You're not supposed to be using kzalloc and dma_map_* calls for large memory regions, and I'm guessing not for long-held mappings either. Typically dma mappings should be temporary for DMA, not long held like these. Now, since hopefully the major annoying underlying problem has also been addressed (ie, ath10k is no longer tears down all of these allocations and reallocates them every time the vdevs are brought down) fragmentation should stop being such a touchy issue. If it is though, using dma_alloc_coherent() use gets us access to the CMB APIs too relatively easily and ideally we would be allocating memory early in boot for exactly these reasons. Signed-off-by: Adrian Chadd <adrian@FreeBSD.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-05-23ath10k: remove unnecessary codeGustavo A. R. Silva
The array fields in struct wmi_start_scan_arg that are checked here are fixed size arrays so they can never be NULL. Addresses-Coverity-ID: 1260031 Cc: Arend Van Spriel <arend.vanspriel@broadcom.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
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-03-16ath10k: fix fetching channel during potential radar detectionMohammed Shafi Shajakhan
Fetch target operating channel during potential radar detection when the interface is just brought up, but no channel is assigned from userspace. In this scenario rx_channel may not be having a valid pointer hence fetch the target operating channel to avoid warnings as below which can be triggered by the commands with DFS testing over longer run comamnds: iw wlan1 set type mesh ifconfig wlan1 up (valid tgt_oper_chan only) iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan) iw wlan1 cac trigger freq 5280 HT20 iw wlan1 cac trigger freq 5300 HT20 Once the CAC expires, current channel context will be removed and we are only left with the fallback option of using 'target operating channel' Firmware and driver log: ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6, count_false=11 ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6, count_false=4 ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar Call trace: WARNING: CPU: 1 PID: 2145 at backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265 cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]() Workqueue: phy1 ieee80211_dfs_radar_detected_work [mac80211] [<c0320770>] (warn_slowpath_null) from [<bf79b90c>] (cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]) [<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from [<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211]) [<bf79697c>] (cfg80211_radar_event [cfg80211]) from [<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211]) [<bf83c058>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4) Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> 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-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-13ath10k: fix wifi connectivity and warning in rx with channel 169Mohammed Shafi Shajakhan
In countries where basic operation of channel 169 is allowed, this fixes the below WARN_ON_ONCE in Rx and fixes the station connectivity failure in channel 169 as the packet is dropped in the driver as the current check limits to channel 165. As of now all the packets beyond channel 165 is dropped, fix this by extending the range to channel 169. Call trace: drivers/net/wireless/ath/ath10k/wmi.c:1505 ath10k_wmi_event_mgmt_rx+0x278/0x440 [ath10k_core]() Call Trace: [<c158f812>] ? printk+0x2d/0x2f [<c105a182>] warn_slowpath_common+0x72/0xa0 [<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440 [<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440 [<c105a1d2>] warn_slowpath_null+0x22/0x30 [<f8b67b58>] ath10k_wmi_event_mgmt_rx+0x278/0x440 [<f8b0e72b>] ? ath10k_pci_sleep+0x8b/0xb0 [ath10k_pci] [<f8b6ac63>] ath10k_wmi_10_2_op_rx+0xf3/0x3b0 [<f8b6495e>] ath10k_wmi_process_rx+0x1e/0x60 [<f8b5f077>] ath10k_htc_rx_completion_handler+0x347/0x4d0 [ath10k_core] [<f8b11dc3>] ? ath10k_ce_completed_recv_next+0x53/0x70 [ath10k_pci] [<f8b0f921>] ath10k_pci_ce_recv_data+0x171/0x1d0 [ath10k_pci] [<f8b0ec69>] ? ath10k_pci_write32+0x39/0x80 [ath10k_pci] [<f8b120bc>] ath10k_ce_per_engine_service+0x5c/0xa0 [ath10k_pci] [<f8b1215f>] ath10k_ce_per_engine_service_any+0x5f/0x70 [ath10k_pci] [<c1060dc0>] ? local_bh_enable_ip+0x90/0x90 [<f8b1048b>] ath10k_pci_tasklet+0x1b/0x50 [ath10k_pci] Fixes: 34c30b0a5e97 ("ath10k: enable advertising support for channel 169, 5Ghz") Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.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>
2016-12-20ath10k: free host-mem with DMA_BIRECTIONAL flagBen Greear
Hopefully this fixes the problem reported by Kalle: Noticed this in my log, but I don't have time to investigate this in detail right now: [ 413.795346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 414.158755] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 477.439659] ath10k_pci 0000:02:00.0: could not get mac80211 beacon [ 481.666630] ------------[ cut here ]------------ [ 481.666669] WARNING: CPU: 0 PID: 1978 at lib/dma-debug.c:1155 check_unmap+0x320/0x8e0 [ 481.666688] ath10k_pci 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x000000002d130000] [size=63800 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE] [ 481.666703] Modules linked in: ctr ccm ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event snd_seq btusb btintel snd_seq_device joydev coret [ 481.671468] CPU: 0 PID: 1978 Comm: rmmod Tainted: G E 4.9.0-rc7-wt+ #54 [ 481.671478] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010 [ 481.671489] ef49dcec c842ee92 c8b5830e ef49dd34 ef49dd20 c80850f5 c8b5a13c ef49dd50 [ 481.671560] 000007ba c8b5830e 00000483 c8461830 c8461830 00000483 ef49ddcc f34e64b8 [ 481.671641] c8b58360 ef49dd3c c80851bb 00000009 00000000 ef49dd34 c8b5a13c ef49dd50 [ 481.671716] Call Trace: [ 481.671731] [<c842ee92>] dump_stack+0x76/0xb4 [ 481.671745] [<c80850f5>] __warn+0xe5/0x100 [ 481.671757] [<c8461830>] ? check_unmap+0x320/0x8e0 [ 481.671769] [<c8461830>] ? check_unmap+0x320/0x8e0 [ 481.671780] [<c80851bb>] warn_slowpath_fmt+0x3b/0x40 [ 481.671791] [<c8461830>] check_unmap+0x320/0x8e0 [ 481.671804] [<c8462054>] debug_dma_unmap_page+0x84/0xa0 [ 481.671835] [<f937cd7a>] ath10k_wmi_free_host_mem+0x9a/0xe0 [ath10k_core] [ 481.671861] [<f9363400>] ath10k_core_destroy+0x50/0x60 [ath10k_core] [ 481.671875] [<f8e13969>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci] [ 481.671889] [<c848d8d8>] pci_device_remove+0x38/0xb0 [ 481.671901] [<c859fe4b>] __device_release_driver+0x7b/0x110 [ 481.671913] [<c85a00e7>] driver_detach+0x97/0xa0 [ 481.671923] [<c859ef8b>] bus_remove_driver+0x4b/0xb0 [ 481.671934] [<c85a0cda>] driver_unregister+0x2a/0x60 [ 481.671949] [<c848c888>] pci_unregister_driver+0x18/0x70 [ 481.671965] [<f8e14dae>] ath10k_pci_exit+0xd/0x25f [ath10k_pci] [ 481.671979] [<c812bb84>] SyS_delete_module+0xf4/0x180 [ 481.671995] [<c81f801b>] ? __might_fault+0x8b/0xa0 [ 481.672009] [<c80037d0>] do_fast_syscall_32+0xa0/0x1e0 [ 481.672025] [<c88d4c88>] sysenter_past_esp+0x45/0x74 [ 481.672037] ---[ end trace 3fd23759e17e1622 ]--- [ 481.672049] Mapped at: [ 481.672060] [ 481.672072] [<c846062c>] debug_dma_map_page.part.25+0x1c/0xf0 [ 481.672083] [ 481.672095] [<c8460799>] debug_dma_map_page+0x99/0xc0 [ 481.672106] [ 481.672132] [<f93745ec>] ath10k_wmi_alloc_chunk+0x12c/0x1f0 [ath10k_core] [ 481.672142] [ 481.672168] [<f937d0c4>] ath10k_wmi_event_service_ready_work+0x304/0x540 [ath10k_core] [ 481.672178] [ 481.672190] [<c80a3643>] process_one_work+0x1c3/0x670 [ 482.137134] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 482.313144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2 [ 482.313274] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2 [ 482.313768] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000 [ 482.313777] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1 [ 482.313974] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498 [ 482.369858] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 [ 482.370011] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 483.596770] ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 [ 483.701686] ath: EEPROM regdomain: 0x0 [ 483.701706] ath: EEPROM indicates default country code should be used [ 483.701713] ath: doing EEPROM country->regdmn map search [ 483.701721] ath: country maps to regdmn code: 0x3a [ 483.701730] ath: Country alpha2 being used: US [ 483.701737] ath: Regpair used: 0x3a Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-01ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONALBen Greear
These memory chunks are often used as 'swap' by the NIC, so it will be both reading and writing to these areas. This seems to fix errors like this on my x86-64 machine: kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000 DMAR:[fault reason 05] PTE Write access is not set Tested-by: Marek Behun <kabel@blackhole.sk> Signed-off-by: Ben Greear <greearb@candelatech.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-10-04ath10k: allow setting coverage classBenjamin Berg
Unfortunately ath10k does not generally allow modifying the coverage class with the stock firmware and Qualcomm has so far refused to implement this feature so that it can be properly supported in ath10k. If we however know the registers that need to be modified for proper operation with a higher coverage class, then we can do these modifications from the driver. This is a hack and might cause subtle problems but as it's not enabled by default (only when user space changes the coverage class explicitly) it should not cause new problems for existing setups. But still this should be considered as an experimental feature and used with caution. This patch implements the support for first generation cards (QCA9880, QCA9887 and so on) which are based on a core that is similar to ath9k. The registers are modified in place and need to be re-written every time the firmware sets them. To achieve this the register status is verified after certain WMI events from the firmware. The coverage class may not be modified temporarily right after the card re-initializes the registers. This is for example the case during scanning. Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially working on a userspace support for this. This patch wouldn't have been possible without this documentation. Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-10-04ath10k: add platform regulatory domain supportBartosz Markowski
This overrides whatever regulatory the device EEPROM contains and uses what the platform says instead - in this implementation the ACPI driver. In case the hint is not programmed or corrupted (0xffff) the device falls back to the eeprom programmed settings. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> [kvalo@qca.qualcomm.com: remove ifdef, change error handling, change info messages to dbg] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-10-04ath10k: provide provision to get Transmit Power Control stats for 10.4Maharaja Kennadyrajan
This patch helps to get the TPC stats for 10.4 fw variants. Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-08-03 01:47:54 +0000