- 10 Apr, 2018 11 commits
-
-
Daniel Mack authored
GFP_ATOMIC should only be used when the allocation is done from atomic context. Introduce a new flag to wcn36xx_dxe_fill_skb() and use GFP_KERNEL when pre-allocating buffers during init. This doesn't fix an issue that was observed in the wild, but it reduces the chance of failed allocations under memory pressure. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Loic Poulain authored
Each DXE control block is associated to a specific channel. The channel lock is always taken before accessing a control block. There is no need to have an extra (useless) spinlock for the control block skb. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Loic Poulain authored
This prevents GCC warning. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Daniel Mack authored
The firmware code cannot cope with requests to remove BSS indices that have not previously been added. This primarily happens when the device is suspended and then resumed. ieee80211_reconfig() then calls into wcn36xx_bss_info_changed() with an empty bssid and BSS_CHANGED_BSSID set, which subsequently leads to a firmware crash: [ 43.647928] qcom-wcnss-pil a204000.wcnss: fatal error received: halMsg.c:4964:halMsg_DelBss: Invalid BSSIndex 0 [ 43.647959] remoteproc remoteproc0: crash detected in a204000.wcnss: type fatal error To fix this, set bss_index to WCN36XX_HAL_BSS_INVALID_IDX for all bss that have not been configured in the firmware, and don't call into the firmware with invalid indices. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Daniel Mack authored
When wcn36xx_dxe_tx_frame() fails to transmit the TX frame, the driver will call into ieee80211_free_txskb() for the skb in flight, so it'll no longer be valid. Hence, we shouldn't keep a reference to it in ctl->skb. Also, if the skb has IEEE80211_TX_CTL_REQ_TX_STATUS set, a pointer to it will currently remain in wcn->tx_ack_skb, which will potentially lead to a crash if accessed later. Fix this by checking the return value of wcn36xx_dxe_tx_frame(), and nullify wcn->tx_ack_skb again in case of errors. Move the assignment of ctl->skb in wcn36xx_dxe_tx_frame() so it only happens when the transmission is successful. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Daniel Mack authored
Bail out if the mapping fails. Even though this hasn't occured during tests, this unlikely case should still be handled. Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wvla, remove accidental use of stack VLA. This avoids an accidental stack VLA (since the compiler thinks the value of FFT_NUM_SAMPLES can change, even when marked "const"). This just replaces it with a #define. Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
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>
-
Marcus Folkesson authored
These allocations are not freed upon release. When on it; go for managed resources instead. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> [kvalo: fix two checkpatch warnings] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
The pointer ndev is being dereferenced before it is being null checked, hence there is a potential null pointer deference. Fix this by only dereferencing ndev after it has been null checked Detected by CoverityScan, CID#1467010 ("Dereference before null check") Fixes: e00243fa ("wil6210: infrastructure for multiple virtual interfaces") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Maya Erez <merez@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Arnd Bergmann authored
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: bc64d052 ("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>
-
- 29 Mar, 2018 18 commits
-
-
Joe Perches authored
Remove the static array and use the generic routine to set the Ethernet broadcast address. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rajkumar Manoharan authored
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>
-
Christian Lamparter authored
The commit "cfg80211: make RATE_INFO_BW_20 the default" changed the index of RATE_INFO_BW_20, but the updates to ath10k missed the special bandwidth calculation case in ath10k_update_per_peer_tx_stats(). This will fix below warning, WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254 cfg80211_calculate_bitrate+0x174/0x220 invalid rate bw=1, mcs=9, nss=2 (unwind_backtrace) from (cfg80211_calculate_bitrate+0x174/0x220) (cfg80211_calculate_bitrate) from (nl80211_put_sta_rate+0x44/0x1dc)from (nl80211_put_sta_rate) from (nl80211_send_station+0x388/0xaf0) (nl80211_get_station+0xa8/0xec) [ end trace da8257d6a850e91a ] Fixes: 842be75c ("cfg80211: make RATE_INFO_BW_20 the default") Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Anilkumar Kolli authored
This patch fixes regression caused by 0c317a02 ("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: 0c317a02 ("cfg80211: support virtual interfaces with different beacon intervals") Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yingying Tang authored
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>
-
Yingying Tang authored
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>
-
Yingying Tang authored
Enable TDLS peer inactivity detetion feature. QCA6174 firmware(version: WLAN.RM.4.4) support TDLS link inactivity detecting. Set related parameters 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>
-
Yingying Tang authored
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>
-
Daniel Mack authored
In case wcn36xx_smd_rsp_process() is called more than once before hal_ind_work was dispatched, the messages will end up in hal_ind_queue, but wcn36xx_ind_smd_work() will only look at the first message in that list. Fix this by dequeing the messages from the list in a loop, and only stop when it's empty. This issue was found during a review of the driver. In my tests, that race never actually occured. Signed-off-by: Daniel Mack <daniel@zonque.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Loic Poulain authored
wcn36xx_start_tx function retrieves the buffer descriptor from the channel control queue to start filling tx buffer information. However, nothing prevents this same buffer to be concurrently accessed in a concurent tx call, leading to potential buffer coruption and firmware crash (observed during iperf test). The channel control queue should only be accessed and updated with the channel lock. Fix this issue by using a local buffer descriptor which will be copied in the thread-safe wcn36xx_dxe_tx_frame. Note that buffer descriptor size is few bytes so the introduced copy overhead is insignificant. Moreover, this allows to keep the locked section minimal. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ramon Fried authored
It appears that the WCN36xx firmware doesn't actually respond to probe requests. Until it's resolved, switch the probe response responsibility to the 802.11 layer to allow creation of hidden SSID AP's. Signed-off-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Anilkumar Kolli authored
QCA9984/QCA99X0/QCA4019 chipsets have 8 memory regions, dump all of them to the firmware coredump file. Some of the regions need to be read using ioread() so add new region types for them. Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> [kvalo: refactoring etc] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Kalle Valo authored
As QCA9984 needs two region types refactor the code to make it easier add the new types. No functional changes. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Sathishkumar Muruganandam authored
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>
-
Ryan Hsu authored
Firmware WLAN.TF.2.1-00014-QCARMSWP-1 now supports reading the board ID information and also required 9 IRAM bank, which older ath10k version don't have the support will fail to be enabled, so in order to maintain the backward compatibility, we need to update the FW API to 6. Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ryan Hsu authored
The firmware of QCA6174/QCA9377 already support the feature, just enable it to be able to handle the get_temperature command and process the event. You can read the temperature by using the hwmon interface, cat /sys/class/ieee80211/phy*/device/hwmon/hwmon2/temp1_input Verified with the following hardware and software combination, QCA6174, only firmware-4.bin doesn't support this, otherwise all support. QCA9377, all the firmwares upstreamed support this command Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Karthikeyan Periyasamy authored
This reverts commit 55884c04. When Ath10k is in AP mode and an unassociated STA sends a VHT action frame (Operating Mode Notification for the NSS change) periodically to AP this causes ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during NSS update. Over the time (with a certain client it can happen within 15 mins when there are over 500 of these VHT action frames) continuous calls of WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust. To my knowledge setting WMI_PEER_NSS peer param itself enough to handle NSS updates and no need to call ath10k_station_assoc(). So revert the original commit from 2014 as it's unclear why the change was really needed. Now the firmware assert doesn't happen anymore. Issue observed in QCA9984 platform with firmware version:10.4-3.5.3-00053. This Change tested in QCA9984 with firmware version: 10.4-3.5.3-00053 and QCA988x platform with firmware version: 10.2.4-1.0-00036. Firmware Assert log: ath10k_pci 0002:01:00.0: firmware crashed! (guid e61f1274-9acd-4c5b-bcca-e032ea6e723c) ath10k_pci 0002:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0002:01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 ath10k_pci 0002:01:00.0: firmware ver 10.4-3.5.3-00053 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast crc32 4c56a386 ath10k_pci 0002:01:00.0: board_file api 2 bmi_id 0:4 crc32 c2271344 ath10k_pci 0002:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath10k_pci 0002:01:00.0: firmware register dump: ath10k_pci 0002:01:00.0: [00]: 0x0000000A 0x000015B3 0x00981E5F 0x00975B31 ath10k_pci 0002:01:00.0: [04]: 0x00981E5F 0x00060530 0x00000011 0x00446C60 ath10k_pci 0002:01:00.0: [08]: 0x0042F1FC 0x00458080 0x00000017 0x00000000 ath10k_pci 0002:01:00.0: [12]: 0x00000009 0x00000000 0x00973ABC 0x00973AD2 ath10k_pci 0002:01:00.0: [16]: 0x00973AB0 0x00960E62 0x009606CA 0x00000000 ath10k_pci 0002:01:00.0: [20]: 0x40981E5F 0x004066DC 0x00400000 0x00981E34 ath10k_pci 0002:01:00.0: [24]: 0x80983B48 0x0040673C 0x000000C0 0xC0981E5F ath10k_pci 0002:01:00.0: [28]: 0x80993DEB 0x0040676C 0x00431AB8 0x0045D0C4 ath10k_pci 0002:01:00.0: [32]: 0x80993E5C 0x004067AC 0x004303C0 0x0045D0C4 ath10k_pci 0002:01:00.0: [36]: 0x80994AAB 0x004067DC 0x00000000 0x0045D0C4 ath10k_pci 0002:01:00.0: [40]: 0x809971A0 0x0040681C 0x004303C0 0x00441B00 ath10k_pci 0002:01:00.0: [44]: 0x80991904 0x0040688C 0x004303C0 0x0045D0C4 ath10k_pci 0002:01:00.0: [48]: 0x80963AD3 0x00406A7C 0x004303C0 0x009918FC ath10k_pci 0002:01:00.0: [52]: 0x80960E80 0x00406A9C 0x0000001F 0x00400000 ath10k_pci 0002:01:00.0: [56]: 0x80960E51 0x00406ACC 0x00400000 0x00000000 ath10k_pci 0002:01:00.0: Copy Engine register dump: ath10k_pci 0002:01:00.0: index: addr: sr_wr_idx: sr_r_idx: dst_wr_idx: dst_r_idx: ath10k_pci 0002:01:00.0: [00]: 0x0004a000 15 15 3 3 ath10k_pci 0002:01:00.0: [01]: 0x0004a400 17 17 212 213 ath10k_pci 0002:01:00.0: [02]: 0x0004a800 21 21 20 21 ath10k_pci 0002:01:00.0: [03]: 0x0004ac00 25 25 27 25 ath10k_pci 0002:01:00.0: [04]: 0x0004b000 515 515 144 104 ath10k_pci 0002:01:00.0: [05]: 0x0004b400 28 28 155 156 ath10k_pci 0002:01:00.0: [06]: 0x0004b800 12 12 12 12 ath10k_pci 0002:01:00.0: [07]: 0x0004bc00 1 1 1 1 ath10k_pci 0002:01:00.0: [08]: 0x0004c000 0 0 127 0 ath10k_pci 0002:01:00.0: [09]: 0x0004c400 1 1 1 1 ath10k_pci 0002:01:00.0: [10]: 0x0004c800 0 0 0 0 ath10k_pci 0002:01:00.0: [11]: 0x0004cc00 0 0 0 0 ath10k_pci 0002:01:00.0: CE[1] write_index 212 sw_index 213 hw_index 0 nentries_mask 0x000001ff ath10k_pci 0002:01:00.0: CE[2] write_index 20 sw_index 21 hw_index 0 nentries_mask 0x0000007f ath10k_pci 0002:01:00.0: CE[5] write_index 155 sw_index 156 hw_index 0 nentries_mask 0x000001ff ath10k_pci 0002:01:00.0: DMA addr: nbytes: meta data: byte swap: gather: ath10k_pci 0002:01:00.0: [455]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [456]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [457]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [458]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [459]: 0x580c0a42 0 0 0 0 ath10k_pci 0002:01:00.0: [460]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [461]: 0x580c0c42 0 0 0 0 ath10k_pci 0002:01:00.0: [462]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [463]: 0x580c0c42 0 0 0 0 ath10k_pci 0002:01:00.0: [464]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [465]: 0x580c0a42 0 0 0 0 ath10k_pci 0002:01:00.0: [466]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [467]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [468]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [469]: 0x580c1c42 0 0 0 0 ath10k_pci 0002:01:00.0: [470]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [471]: 0x580c1c42 0 0 0 0 ath10k_pci 0002:01:00.0: [472]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [473]: 0x580c1c42 0 0 0 0 ath10k_pci 0002:01:00.0: [474]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [475]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [476]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [477]: 0x580c0842 0 0 0 0 ath10k_pci 0002:01:00.0: [478]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [479]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [480]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [481]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [482]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [483]: 0x580c0842 0 0 0 0 ath10k_pci 0002:01:00.0: [484]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [485]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [486]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [487]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [488]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [489]: 0x580c0842 0 0 0 0 ath10k_pci 0002:01:00.0: [490]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [491]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [492]: 0x58174040 0 1 0 0 ath10k_pci 0002:01:00.0: [493]: 0x5a946040 0 1 0 0 ath10k_pci 0002:01:00.0: [494]: 0x59909040 0 1 0 0 ath10k_pci 0002:01:00.0: [495]: 0x5ae5a040 0 1 0 0 ath10k_pci 0002:01:00.0: [496]: 0x58096040 0 1 0 0 ath10k_pci 0002:01:00.0: [497]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [498]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [499]: 0x5c1e0040 0 1 0 0 ath10k_pci 0002:01:00.0: [500]: 0x58153040 0 1 0 0 ath10k_pci 0002:01:00.0: [501]: 0x58129040 0 1 0 0 ath10k_pci 0002:01:00.0: [502]: 0x5952f040 0 1 0 0 ath10k_pci 0002:01:00.0: [503]: 0x59535040 0 1 0 0 ath10k_pci 0002:01:00.0: [504]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [505]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [506]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [507]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [508]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [509]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [510]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [511]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [512]: 0x5adcc040 0 1 0 0 ath10k_pci 0002:01:00.0: [513]: 0x5cf3d040 0 1 0 0 ath10k_pci 0002:01:00.0: [514]: 0x5c1e9040 64 1 0 0 ath10k_pci 0002:01:00.0: [515]: 0x00000000 0 0 0 0 Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Timothy Redaelli authored
some userspace programs (e.g. hostapd) need to set the regulatory domain before selecting the operating channel. Synchronize DFS detector regardless of the value of ah->curchan, to avoid situations where wireless scan can't be done on some 5GHz sub-bands, because dfs_region is constantly UNSET. Acked-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Timothy Redaelli <tredaelli@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 27 Mar, 2018 5 commits
-
-
Tobin C. Harding authored
The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug (kernel Oops) or a security flaw (overwriting memory beyond the stack). Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. As part of the directive[1] to remove all VLAs from the kernel, and build with -Wvla. Currently rsi code uses a VLA based on a function argument to `rsi_sdio_load_data_master_write()`. The function call chain is Both these functions rsi_sdio_reinit_device() rsi_probe() start the call chain: rsi_hal_device_init() rsi_load_fw() auto_fw_upgrade() ping_pong_write() rsi_sdio_load_data_master_write() [Without familiarity with the code] it appears that none of the 4 locks mutex rx_mutex tx_mutex tx_bus_mutex are held when `rsi_sdio_load_data_master_write()` is called. It is therefore safe to use kmalloc with GFP_KERNEL. We can avoid using the VLA by using `kmalloc()` and free'ing the memory on all exit paths. Change buffer from 'u8 array' to 'u8 *'. Call `kmalloc()` to allocate memory for the buffer. Using goto statement to call `kfree()` on all return paths. It can be expected that this patch will result in a small increase in overhead due to the use of `kmalloc()` however this code is only called on initialization (and re-initialization) so this overhead should not degrade performance. [1] https://lkml.org/lkml/2018/3/7/621Signed-off-by: Tobin C. Harding <me@tobin.cc> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ganapathi Bhat authored
Fix the following sparse warning in mwifiex_cmd_append_11n_tlv: drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:358:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:358:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:360:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:360:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:360:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:366:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:366:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:366:65: right side has type int drivers/net/wireless/marvell/mwifiex/11n.c:368:65: warning: invalid assignment: &= drivers/net/wireless/marvell/mwifiex/11n.c:368:65: left side has type restricted __le16 drivers/net/wireless/marvell/mwifiex/11n.c:368:65: right side has type int Fixes: 77423fa7 ("mwifiex: fix incorrect ht capability problem") Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Joe Perches authored
Prefer the direct use of octal for permissions. Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace and some typing. Miscellanea: o Whitespace neatening around these conversions. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Arnd Bergmann authored
The linkage between the bluetooth driver and the wireless driver is not defined properly, leading to build problems such as: warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt': (.text+0x205): undefined reference to `rsi_bt_ops' As the dependency is actually the reverse (RSI_91X uses the BT_RSI driver, not the other way round), this changes the dependency to match, and enables the bluetooth driver from the RSI_COEX symbol. Fixes: 38aa4da5 ("Bluetooth: btrsi: add new rsi bluetooth driver") Acked-by; Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.17. Major changes: wil6210 * support multiple virtual interfaces
-
- 26 Mar, 2018 6 commits
-
-
Ramon Fried authored
IRQ reason was not cheked for errors. Although error handing is not currently supported, it will be nice to output an error value to the log if the DMA operation failed. Signed-off-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ramon Fried authored
DXE channel defaults used hardcoded magic values. Added bit definitions of the control register and calculate this values in compilation for clarity. Signed-off-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ramon Fried authored
DXE descriptor control registers used hardcoded magic values. Added bit definitions of the control register and calculate this values in compilation for clarity. No functional changes. Signed-off-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Peter Große authored
Signed-off-by: Peter Große <pegro@friiks.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Sebastian Gottschall authored
Fixes crash seen on arm smp systems (gateworks ventana imx6): Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = 80004000 [00000014] *pgd=00000000 Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM Modules linked in: ip6table_filter nf_conntrack_ipv6 ip6_tables nf_log_ipv6 nf_defrag_ipv6 shortcut_fe ipcomp6 xfrm_ipcomp xfrm6_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet ip6_tunnel tunnel6 mip6 ah6 esp6 xfrm_algo sit ip_tunnel tunnel4 ipv6 ath10k_pci ath10k_core ath9k ath mac80211 cfg80211 compat ath_pci ath_hal(P) caamalg authencesn authenc caamrng caamhash caam_jr caam cdc_ncm usbnet usbcore sky2 imx2_wdt CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: P 4.9.85 #19 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) task: bf064980 task.stack: bf07c000 PC is at relay_buf_full+0xc/0x30 LR is at _674+0x740/0xf10 [ath9k] pc : [<8018bce0>] lr : [<7f1aa604>] psr: 80000013 sp : bf07dbf0 ip : bf07dc00 fp : bf07dbfc r10: 0000003f r9 : bf130e00 r8 : 809044b0 r7 : 00000000 r6 : be67a9f0 r5 : 00000000 r4 : 809043e4 r3 : c0864c24 r2 : 00000000 r1 : 00000004 r0 : 00000000 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 4e6a004a DAC: 00000055 Process ksoftirqd/0 (pid: 3, stack limit = 0xbf07c210) Stack: (0xbf07dbf0 to 0xbf07e000) dbe0: bf07dd04 bf07dc00 7f1aa604 8018bce0 dc00: 00004014 be59e010 bf07dc34 bf07dc18 7f1a7084 7f19c07c be59c010 be6470a0 dc20: 0000096c be648954 bf07dc6c bf07dc38 7f1c286c bf07dd90 bf07dc5c bf07dc48 dc40: 8029ea4c 0000003c 00000001 be59c010 00000094 00000000 00000000 00000000 dc60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dc80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dca0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dcc0: 00000000 00000000 00000000 00000000 00000000 00000000 8010ef24 00000030 dce0: be94f5e8 be6485a0 bddf0200 be59c010 be6465a0 be6415a0 bf07ddf4 bf07dd08 dd00: 7f1cf800 7f1aa55c 1fc38c4c 00000000 bf07dd58 cccccccd 66666667 be640bc0 dd20: bf07dd54 be6415a0 1fc38c4c 00000000 00000000 be59c038 be67a9c0 be59e010 dd40: be67a9f0 be647170 8090c904 be59c010 00000000 00000001 1fc38e84 00000000 dd60: be640bc0 bddf0200 00000200 00000010 0000003f 00000002 20000013 be59c010 dd80: 8092d940 bf7ca2c0 bf07ddb4 bf07dd98 1fc38c4c 2602003f 0100ff1b 80ff1b00 dda0: 00808080 00000000 00000000 80808080 80808080 80808080 80808080 00008080 ddc0: 00000000 00000000 7f1b62b8 00000002 be6470ec be6470f0 00000000 bf07de98 dde0: 8092d940 be6415a0 bf07de94 bf07ddf8 7f1d1ed8 7f1cf1fc 00000000 00000000 de00: bf7cc4c0 00000400 be6470f0 bf07de18 8015165c be59c010 8090453c 8090453c de20: bf07dec4 be6465a0 8014f614 80148884 0000619a 00000001 bf07c000 00000100 de40: bf07de78 00000001 7f327850 00000002 afb50401 bf064980 bf07de9c bf07de68 de60: bf064a00 803cc668 bf064a00 be6470b4 be6470b8 80844180 00000000 bf07de98 de80: 8092d940 bf07c000 bf07dec4 bf07de98 80124d18 7f1d1c44 80124c94 00000000 dea0: 00000006 80902098 80902080 40000006 00000100 bf07c000 bf07df24 bf07dec8 dec0: 8012501c 80124ca0 bf7cc4c0 bf064980 be95e1c0 04208040 80902d00 000061c7 dee0: 0000000a 80600b54 8092d940 808441f8 80902080 bf07dec8 bf03b200 bf07c000 df00: bf03b200 8090fe54 00000000 00000000 00000000 00000000 bf07df34 bf07df28 df20: 80125148 80124f28 bf07df5c bf07df38 8013deb4 8012511c 00000000 bf03b240 df40: bf03b200 8013dc90 00000000 00000000 bf07dfac bf07df60 8013ad40 8013dc9c df60: 70448040 00000001 00000000 bf03b200 00000000 00030003 bf07df78 bf07df78 df80: 00000000 00000000 bf07df88 bf07df88 bf03b240 8013ac48 00000000 00000000 dfa0: 00000000 bf07dfb0 80107760 8013ac54 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 8c120004 1190ad04 Backtrace: [<8018bcd4>] (relay_buf_full) from [<7f1aa604>] (_674+0x740/0xf10 [ath9k]) [<7f1aa550>] (_674 [ath9k]) from [<7f1cf800>] (_582+0x14b4/0x3708 [ath9k]) r10:be6415a0 r9:be6465a0 r8:be59c010 r7:bddf0200 r6:be6485a0 r5:be94f5e8 r4:00000030 [<7f1cf1f0>] (_582 [ath9k]) from [<7f1d1ed8>] (_735+0x2a0/0xec4 [ath9k]) r10:be6415a0 r9:8092d940 r8:bf07de98 r7:00000000 r6:be6470f0 r5:be6470ec r4:00000002 [<7f1d1c38>] (_735 [ath9k]) from [<80124d18>] (tasklet_action+0x84/0xf8) r10:bf07c000 r9:8092d940 r8:bf07de98 r7:00000000 r6:80844180 r5:be6470b8 r4:be6470b4 [<80124c94>] (tasklet_action) from [<8012501c>] (__do_softirq+0x100/0x1f4) r10:bf07c000 r9:00000100 r8:40000006 r7:80902080 r6:80902098 r5:00000006 r4:00000000 r3:80124c94 [<80124f1c>] (__do_softirq) from [<80125148>] (run_ksoftirqd+0x38/0x4c) r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:8090fe54 r5:bf03b200 r4:bf07c000 [<80125110>] (run_ksoftirqd) from [<8013deb4>] (smpboot_thread_fn+0x224/0x260) [<8013dc90>] (smpboot_thread_fn) from [<8013ad40>] (kthread+0xf8/0x100) r9:00000000 r8:00000000 r7:8013dc90 r6:bf03b200 r5:bf03b240 r4:00000000 [<8013ac48>] (kthread) from [<80107760>] (ret_from_fork+0x14/0x34) r7:00000000 r6:00000000 r5:8013ac48 r4:bf03b240 Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5901014) ---[ end trace dddf11ac9111b272 ]--- Kernel panic - not syncing: Fatal exception in interrupt CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: P D 4.9.85 #19 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<8010a708>] (dump_backtrace) from [<8010a99c>] (show_stack+0x18/0x1c) r7:bf093f58 r6:20000193 r5:809168e8 r4:00000000 [<8010a984>] (show_stack) from [<802a09c4>] (dump_stack+0x94/0xa8) [<802a0930>] (dump_stack) from [<8010d184>] (handle_IPI+0xe8/0x180) r7:bf093f58 r6:00000000 r5:00000001 r4:808478c4 [<8010d09c>] (handle_IPI) from [<801013e8>] (gic_handle_irq+0x78/0x7c) r7:f4000100 r6:bf093f58 r5:f400010c r4:8090467c [<80101370>] (gic_handle_irq) from [<8010b378>] (__irq_svc+0x58/0x8c) Exception stack(0xbf093f58 to 0xbf093fa0) 3f40: bf7d62a0 00000000 3f60: 0010a5f4 80113460 bf092000 809043e4 00000002 80904434 bf092008 412fc09a 3f80: 00000000 bf093fb4 bf093fb8 bf093fa8 8010804c 80108050 60000013 ffffffff r9:bf092000 r8:bf092008 r7:bf093f8c r6:ffffffff r5:60000013 r4:80108050 [<80108014>] (arch_cpu_idle) from [<80553c2c>] (default_idle_call+0x30/0x34) [<80553bfc>] (default_idle_call) from [<80158394>] (cpu_startup_entry+0xc4/0xfc) [<801582d0>] (cpu_startup_entry) from [<8010ce40>] (secondary_start_kernel+0x168/0x174) r7:8092d2f8 r4:80913568 [<8010ccd8>] (secondary_start_kernel) from [<10101488>] (0x10101488) r5:00000055 r4:4f07806a Rebooting in 10 seconds.. Reboot failed -- System halted Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Karthikeyan Periyasamy authored
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>
-