summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2021-06-15rt2x00: remove leading spaces before tabsHui Tang1-1/+1
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.c' | xargs sed -r -i 's/^[ ]+\t/\t/' $ find . -name '*.h' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621407345-10625-3-git-send-email-tanghui20@huawei.com
2021-06-15libertas: remove leading spaces before tabsHui Tang1-1/+1
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.c' | xargs sed -r -i 's/^[ ]+\t/\t/' $ find . -name '*.h' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621407345-10625-2-git-send-email-tanghui20@huawei.com
2021-06-15wlcore: Fix missing function name in commentsYang Shen1-3/+3
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/ti/wlcore/cmd.c:824: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/net/wireless/ti/wlcore/cmd.c:853: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/net/wireless/ti/wlcore/cmd.c:882: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-12-shenyang39@huawei.com
2021-06-15rsi: Fix missing function name in commentsYang Shen1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/rsi/rsi_91x_mgmt.c:1550: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-10-shenyang39@huawei.com
2021-06-15rtlwifi: Fix wrong function name in commentsYang Shen1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:124: warning: expecting prototype for writeLLT(). Prototype was for rtl92c_llt_write() instead drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:154: warning: expecting prototype for rtl92c_init_LLT_table(). Prototype was for rtl92c_init_llt_table() instead Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-9-shenyang39@huawei.com
2021-06-15libertas_tf: Fix wrong function name in commentsYang Shen1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/marvell/libertas_tf/if_usb.c:56: warning: expecting prototype for if_usb_wrike_bulk_callback(). Prototype was for if_usb_write_bulk_callback() instead Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-8-shenyang39@huawei.com
2021-06-15brcmsmac: Remove the repeated declarationShaokun Zhang1-1/+0
Function 'brcms_c_stf_phy_txant_upd' are declared twice, remove the repeated declaration. Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621844443-38290-1-git-send-email-zhangshaokun@hisilicon.com
2021-06-15brcmsmac: mac80211_if: Fix a resource leak in an error handling pathChristophe JAILLET1-1/+7
If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()' as already done in the remove function. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr
2021-06-15brcmsmac: Drop unnecessary NULL check after container_ofGuenter Roeck1-3/+0
The parameter passed to ai_detach() is guaranteed to never be NULL because it is checked by the caller. Consequently, the result of container_of() on it is also never NULL, and a NULL check on it is unnecessary. Even without that, the NULL check would still be unnecessary because the subsequent kfree() can handle NULL arguments. On top of all that, it is misleading to check the result of container_of() against NULL because the position of the contained element could change, which would make the check invalid. Remove it. This change was made automatically with the following Coccinelle script. @@ type t; identifier v; statement s; @@ <+... ( t v = container_of(...); | v = container_of(...); ) ... when != v - if (\( !v \| v == NULL \) ) s ...+> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511235629.1686038-1-linux@roeck-us.net
2021-06-15brcmsmac: improve readability on addresses copyÍñigo Huguet1-1/+2
A static analyzer identified as a potential bug the copy of 12 bytes from a 6 bytes array to a 6 bytes array. Both arrays are 6 bytes addresses. Although not being a real bug, it is not immediately clear why is done this way: next 6 bytes address, contiguous to the first one, must also be copied to next contiguous 6 bytes address of the destination. Copying each one separately will make both static analyzers and reviewers happier. Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511070257.7843-1-ihuguet@redhat.com
2021-06-15brcmfmac: Add clm_blob firmware files to modinfoMatthias Brugger3-8/+15
Cypress Wi-Fi chipsets include information regarding regulatory constraints. These are provided to the driver through "Country Local Matrix" (CLM) blobs. Files present in Linux firmware repository are on a generic world-wide safe version with conservative power settings which is designed to comply with regulatory but may not provide best performance on all boards. Never the less, a better functionality can be expected with the file present, so add it to the modinfo of the driver. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210607103433.21022-1-matthias.bgg@kernel.org
2021-06-15brcmfmac: Delete second brcm folder hierarchyMatthias Brugger1-2/+2
BRCMF_FW_DEFAULT_PATH already defines the brcm folder, delete the second folder to match with Linux firmware repository layout. Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo") Signed-off-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210602144305.4481-1-matthias.bgg@kernel.org
2021-06-15brcmfmac: Fix a double-free in brcmf_sdio_bus_resetTong Tiangen1-1/+0
brcmf_sdiod_remove has been called inside brcmf_sdiod_probe when fails, so there's no need to call another one. Otherwise, sdiodev->freezer would be double freed. Fixes: 7836102a750a ("brcmfmac: reset SDIO bus on a firmware crash") Signed-off-by: Tong Tiangen <tongtiangen@huawei.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210601100128.69561-1-tongtiangen@huawei.com
2021-06-15brcmfmac: Demote non-compliant kernel-doc headersYang Shen2-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:2040: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1295: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-5-shenyang39@huawei.com
2021-06-15brcmfmac: correctly report average RSSI in station infoAlvin Šipraga1-16/+20
The rx_lastpkt_rssi field provided by the firmware is suitable for NL80211_STA_INFO_{SIGNAL,CHAIN_SIGNAL}, while the rssi field is an average. Fix up the assignments and set the correct STA_INFO bits. This lets userspace know that the average RSSI is part of the station info. Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210506132010.3964484-2-alsi@bang-olufsen.dk
2021-06-15brcmfmac: fix setting of station info chains bitmaskAlvin Šipraga1-2/+1
The sinfo->chains field is a bitmask for filled values in chain_signal and chain_signal_avg, not a count. Treat it as such so that the driver can properly report per-chain RSSI information. Before (MIMO mode): $ iw dev wlan0 station dump ... signal: -51 [-51] dBm After (MIMO mode): $ iw dev wlan0 station dump ... signal: -53 [-53, -54] dBm Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210506132010.3964484-1-alsi@bang-olufsen.dk
2021-06-15brcmfmac: use ISO3166 country code and 0 rev as fallbackShawn Guo1-6/+11
Instead of aborting country code setup in firmware, use ISO3166 country code and 0 rev as fallback, when country_codes mapping table is not configured. This fallback saves the country_codes table setup for recent brcmfmac chipsets/firmwares, which just use ISO3166 code and require no revision number. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210425110200.3050-1-shawn.guo@linaro.org
2021-06-14wlcore: fix read pointer updateRussell King1-8/+2
When reading the fw_log structure from the device's memory, we could race with the firmware updating the actual_buff_size and buff_write_ptr members of this structure. This would lead to bytes being dropped from the log. Fix this by writing back the actual - now fixed - clear_ptr which reflects where we read up to in the buffer. This also means that we must not check that the clear_ptr matches the current write pointer, so remove that check. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/E1lolvi-0003Ri-39@rmk-PC.armlinux.org.uk
2021-06-14wlcore: fix bug reading fwlogRussell King1-0/+2
With logging enabled, it has been observed that the driver spews messages such as: wlcore: ERROR Calculate of clear addr Clear = 204025b0, write = 204015b0 The problem occurs because 204025b0 is the end of the buffer, and 204015b0 is the beginning, and the calculation for "clear"ing the buffer does not take into account that if we read to the very end of the ring buffer, we are actually at the beginning of the buffer. Fix this. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/E1lolvc-0003RM-VE@rmk-PC.armlinux.org.uk
2021-06-14wlcore: make some of the fwlog calculations more obviousRussell King1-15/+28
Make some of the fwlog calculations more obvious by calculating bits that get used and documenting what they are. Validate the read pointer while we're at it to ensure we do not overflow the data block we have allocated and read. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/E1lolvX-0003R3-RE@rmk-PC.armlinux.org.uk
2021-06-14wlcore: tidy up use of fw_log.actual_buff_sizeRussell King1-10/+10
Tidy up the use of fw_log.actual_buff_size - rather than reading it multiple times and applying the endian conversion, read it once into actual_len and use that instead. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/E1lolvS-0003Ql-NJ@rmk-PC.armlinux.org.uk
2021-06-14wlcore/wl12xx: Fix wl12xx get_mac error if device is in ELPTony Lindgren1-0/+7
At least on wl12xx, reading the MAC after boot can fail with a warning at drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read. The failed call comes from wl12xx_get_mac() that wlcore_nvs_cb() calls after request_firmware_work_func(). After the error, no wireless interface is created. Reloading the wl12xx module makes the interface work. Turns out the wlan controller can be in a low-power ELP state after the boot from the bootloader or kexec, and needs to be woken up first. Let's wake the hardware and add a sleep after that similar to wl12xx_pre_boot() is already doing. Note that a similar issue could exist for wl18xx, but I have not seen it so far. And a search for wl18xx_get_mac and wl12xx_sdio_raw_read did not produce similar errors. Cc: Carl Philipp Klemm <philipp@uvos.xyz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210603062814.19464-1-tony@atomide.com
2021-06-14wlcore: use DEVICE_ATTR_<RW|RO> macroYueHaibing1-13/+11
Use DEVICE_ATTR_<RW|RO> helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210523033538.25568-1-yuehaibing@huawei.com
2021-06-14wcn36xx: Move hal_buf allocation to devm_kmalloc in probeBryan O'Donoghue1-13/+8
Right now wcn->hal_buf is allocated in wcn36xx_start(). This is a problem since we should have setup all of the buffers we required by the time ieee80211_register_hw() is called. struct ieee80211_ops callbacks may run prior to mac_start() and therefore wcn->hal_buf must be initialized. This is easily remediated by moving the allocation to probe() taking the opportunity to tidy up freeing memory by using devm_kmalloc(). Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605173347.2266003-1-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Fix inconsistent indentingJiapeng Chong1-1/+1
Eliminate the follow smatch warning: drivers/net/wireless/ath/wcn36xx/dxe.c:803 wcn36xx_dxe_tx_frame() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1622024568-32130-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-06-14wcn36xx: Enable WOWLAN flagsBryan O'Donoghue1-1/+3
Enable flags for - Magic packet - GTK rekey Previous patches implemented the necessary code to switch these two on. Standalone magic packet absent GTK rekey is pretty useless, so it makes sense to flag both at once. Once done it is possible for wcn36xx firmware to 1. Respond to ipv4 and ipv6 ARP/NS lookup requests 2. Bring the system out of suspend when a magic packet is received. Magic in our case is a simple ipv4 or ipv6 unicast. 3. GTK rekey whilst in suspend Once we wake from suspend the GTK will be updated as necessary Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-13-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add host resume request supportBryan O'Donoghue3-0/+38
This commit is the corresponding resume() path request to the firmware when resuming. Unlike the suspend() version which is a unidirectional indication, the resume version is a standard request/response. Once the resume() request completes ipv4 ARP, ipv6 NS and GTK rekey offload stop working and can subsequently be rolled back. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-12-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add Host suspend indication supportBryan O'Donoghue3-0/+24
In order to activate ipv4 ARP offload, ipv6 NS offload and firmware GTK offload we need to send a unidirectional indication from host to wcn indicating a transition to suspend. Once done, firmware will respond to ARP broadcasts, ipv6 NS lookups and perform GTK rekeys without waking the host. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-11-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add GTK offload info to WoWLAN resumeBryan O'Donoghue4-2/+79
Having enabled GTK rekey in suspend, we need to extract the replay counter from the firmware on resume and perform a ieee80211_gtk_rekey_notify() so that the STA remains verified from the perspective of the AP. In order to enable the SMD command and response we need to pack the existing command/response structures. Given these structures are currently unused, there's no need to backport this as a fix. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-10-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add GTK offload to WoWLAN pathBryan O'Donoghue4-1/+47
Using previously set GTK KCK and KEK material this commit adds GTK rekeying to the WoWLAN suspend/resume path. A small error in the packing of the up to now unused command structure is fixed as we go. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-9-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add set_rekey_data callbackBryan O'Donoghue2-0/+25
Add a callback for Group Temporal Key tracking as provided by the standard WiFi ops structure. We track the key to integrate GTK offloading into the WoWLAN suspend path later on. Code comes from the Intel iwlwifi driver with minimal name changes. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-8-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add ipv6 namespace offload in suspendBryan O'Donoghue4-0/+73
We need to respond to ipv6 namespace lookups when in suspend. This patch adds the necessary changes to issue the appropriate firmware command on suspend and resume to enter/exit firmware offloaded ns lookup. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-7-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add ipv6 address trackingBryan O'Donoghue3-0/+41
Taking code from iwlwifi this commit adds a standard callback for ipv6_addr_change(). This callback allows wcn36xx to know the set of ipv6 addresses. Something we need to know in order to get wowlan working with ipv6. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-6-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Do not flush indication queue on suspend/resumeBryan O'Donoghue1-2/+0
Testing on Android reveals that the flush on both suspend and resume of the firmware indication work-queue can stall indefinitely. Given this code path doesn't appear to have been exercised up until now, removing this flush to unblock this situation. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-5-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Add ipv4 ARP offload support in suspendBryan O'Donoghue4-8/+57
Add ARP offload support. Firmware is capable of responding to ARP requests for a single ipv4 address only. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-4-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Run suspend for the first ieee80211_vifBryan O'Donoghue1-3/+28
A subsequent set of patches will extend out suspend/resume support in this driver, we cannot set the firmware up for multiple ipv4/ipv6 addresses and as such we can't iterate through a list of ieee80211_vif. Constrain the interaction with the firmware to the first ieee80211_vif on the suspend/resume/wowlan path. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-3-bryan.odonoghue@linaro.org
2021-06-14wcn36xx: Return result of set_power_params in suspendBryan O'Donoghue1-2/+4
wcn36xx_smd_set_power_params() can return an error. For the purposes of entering into suspend we need the suspend() function to trap and report errors up the stack. First step in this process is reporting the existing result code for wcn36xx_smd_set_power_params(). Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605011140.2004643-2-bryan.odonoghue@linaro.org
2021-06-14Merge tag 'v5.13-rc6' into driver-core-nextGreg Kroah-Hartman11-30/+138
We need the driver core fix in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-12ath10k: remove unused more_frags variableYang Yingliang1-2/+0
Fix the following W=1 build warning: drivers/net/wireless/ath/ath10k/htt_rx.c:1790:7: warning: variable ‘more_frags’ set but not used [-Wunused-but-set-variable] 1790 | bool more_frags; | ^~~~~~~~~~ Fixes: a1166b2653db ("ath10k: add CCMP PN replay protection for fragmented frames for PCIe") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210526142219.2542528-1-yangyingliang@huawei.com
2021-06-12wireless: carl9170: fix LEDS build errors & warningsRandy Dunlap1-5/+3
kernel test robot reports over 200 build errors and warnings that are due to this Kconfig problem when CARL9170=m, MAC80211=y, and LEDS_CLASS=m. WARNING: unmet direct dependencies detected for MAC80211_LEDS Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y]) Selected by [m]: - CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && CARL9170 [=m] CARL9170_LEDS selects MAC80211_LEDS even though its kconfig dependencies are not met. This happens because 'select' does not follow any Kconfig dependency chains. Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where the latter supplies any needed dependencies on LEDS_CLASS. Fixes: 1d7e1e6b1b8ed ("carl9170: Makefile, Kconfig files and MAINTAINERS") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: linux-wireless@vger.kernel.org Cc: Arnd Bergmann <arnd@arndb.de> Suggested-by: Christian Lamparter <chunkeey@googlemail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210530031134.23274-1-rdunlap@infradead.org
2021-06-12ath10k: add missing error return code in ath10k_pci_probe()Yang Yingliang1-3/+9
When chip_id is not supported, the resources will be freed on path err_unsupported, these resources will also be freed when calling ath10k_pci_remove(), it will cause double free, so return -ENODEV when it doesn't support the device with wrong chip_id. Fixes: c0c378f9907c ("ath10k: remove target soc ps code") Fixes: 7505f7c3ec1d ("ath10k: create a chip revision whitelist") Fixes: f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210522105822.1091848-3-yangyingliang@huawei.com
2021-06-12ath10k: go to path err_unsupported when chip id is not supportedYang Yingliang1-1/+1
When chip id is not supported, it go to path err_unsupported to print the error message. Fixes: f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210522105822.1091848-2-yangyingliang@huawei.com
2021-06-12ath11k: don't call ath11k_pci_set_l1ss for WCN6855Baochen Qiang3-1/+8
For QCA6390, one PCI related clock drifts sometimes, and it makes PCI link difficult to quit L1ss. Current implementation fixed this by configuring some related regs using ath11k_pci_fix_l1ss. WCN6855 does not have this clock drift problem, so no need to set these regs. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-8-jouni@codeaurora.org
2021-06-12ath11k: add support for WCN6855Baochen Qiang4-10/+75
This patch is to add support for WCN6855. For station mode, WCN6855 is able to connect to an AP, and ping works well. For AP mode, hostapd is able to bringup an SAP interface with WCN6855, a normal station can connect to this AP and ping works well. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-7-jouni@codeaurora.org
2021-06-12ath11k: add support to get peer id for WCN6855Baochen Qiang4-4/+38
For WCN6855, the layout of hal rx mpdu info is different, so need to handle this target differently when getting peer id. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-6-jouni@codeaurora.org
2021-06-12ath11k: setup WBM_IDLE_LINK ring once againBaochen Qiang1-0/+10
For WCN6855, WBM idle link ring needs a reinit. Without this reinit, firmware crash might happen occasionally. This is requested by the hw team. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-5-jouni@codeaurora.org
2021-06-12ath11k: setup REO for WCN6855Baochen Qiang5-52/+96
WCN6855 needs a different reo configuration, so add separate handling for this target in ath11k_hw_ops. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-4-jouni@codeaurora.org
2021-06-12ath11k: add dp support for WCN6855Baochen Qiang3-0/+289
hal rx descriptor is different for WCN6855 and there are such a lot of handlers processing this descriptor in data path. So add separate handling for this target. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-3-jouni@codeaurora.org
2021-06-12ath11k: add hw reg support for WCN6855Baochen Qiang2-0/+72
Reg address of WCN6855 is different from other devices, so add separate reg definition for this target. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Govind Singh <govinds@codeaurora.org> Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210511162214.29475-2-jouni@codeaurora.org
2021-06-12ath9k: Fix kernel NULL pointer dereference during ath_reset_internal()Pali Rohár1-0/+5
I got this crash more times during debugging of PCIe controller and crash happens somehow at the time when PCIe kernel code started link retraining (as part of ASPM code) when at the same time PCIe link went down and ath9k probably executed hw reset procedure. Currently I'm not able to reproduce this issue as it looks like to be some race condition between link training, ASPM, link down and reset path. And as always, race conditions which depends on more input parameters are hard to reproduce as it depends on precise timings. But it is clear that pointers are zero in this case and should be properly filled as same code pattern is used in ath9k_stop() function. Anyway I was able to reproduce this crash by manually triggering ath reset worker prior putting card up. I created simple patch to export reset functionality via debugfs and use it to "simulate" of triggering reset. s proved that NULL-pointer dereference issue is there. Function ath9k_hw_reset() is dereferencing chan structure pointer, so it needs to be non-NULL pointer. Function ath9k_stop() already contains code which sets ah->curchan to valid non-NULL pointer prior calling ath9k_hw_reset() function. Add same code pattern also into ath_reset_internal() function to prevent kernel NULL pointer dereference in ath9k_hw_reset() function. This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL chan structure. [ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 45.344417] Mem abort info: [ 45.347301] ESR = 0x96000005 [ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits [ 45.356166] SET = 0, FnV = 0 [ 45.359350] EA = 0, S1PTW = 0 [ 45.362596] Data abort info: [ 45.365756] ISV = 0, ISS = 0x00000005 [ 45.369735] CM = 0, WnR = 0 [ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000 [ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 45.388856] Internal error: Oops: 96000005 [#1] SMP [ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw [ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785 [ 45.414746] Workqueue: phy0 ath_reset_work [ath9k] [ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw] [ 45.436548] sp : ffffffc0118dbca0 [ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000 [ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000 [ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000 [ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408 [ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8 [ 45.467366] x19: 0000000000000000 x18: 0000000000000000 [ 45.472846] x17: 0000000000000000 x16: 0000000000000000 [ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff [ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720 [ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0 [ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8 [ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001 [ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000 [ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870 [ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f [ 45.522174] Call trace: [ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k] [ 45.534696] ath_reset_work+0x2c/0x40 [ath9k] [ 45.539198] process_one_work+0x210/0x480 [ 45.543339] worker_thread+0x5c/0x510 [ 45.547115] kthread+0x12c/0x130 [ 45.550445] ret_from_fork+0x10/0x1c [ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61) [ 45.560430] ---[ end trace 566410ba90b50e8b ]--- [ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 45.572282] SMP: stopping secondary CPUs [ 45.576331] Kernel Offset: disabled [ 45.579924] CPU features: 0x00040002,0000200c [ 45.584416] Memory Limit: none [ 45.587564] Rebooting in 3 seconds.. Signed-off-by: Pali Rohár <pali@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 00:21:49 +0300