summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-11-06brcmutil: print invalid chanspec when WARN-ingRafał Miłecki
On one of my devices I got WARNINGs when brcmfmac tried to decode chanspec. I couldn't tell if it was some unsupported format or just a malformed value passed by a firmware. Print chanspec value so it's possible to debug a possible problem. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06wireless: airo: potential buffer overflow in sprintf()Dan Carpenter
It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes of the ssid, but we accidentally use "%*s" (width) instead of "%.*s" (precision) so if the ssid doesn't have a NUL terminator this could lead to an overflow. Static analysis. Not tested. Fixes: e174961ca1a0 ("net: convert print_mac to %pM") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rtlwifi: Remove same duplicated includeszhong jiang
Just remove same duplicated includes. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rtlwifi: rtl8723ae: Remove set but not used variables and #defineszhong jiang
radiob_array_table' and 'radiob_arraylen' are not used after setting its value. It is safe to remove the unused variable. Meanwhile, radio B array should be removed as well. because it will no longer be referenced. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmsmac: never log "tid x is not agg'able" by defaultAli MJ Al-Nasrawy
This message greatly spams the log under heavy Tx of frames with BK access class which is especially true when operating as AP. It is also not informative as the "agg'ablity" of TIDs are set once and never change. Fix this by logging only in debug mode. Signed-off-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06zd1201: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rtlwifi: rtl8821ae: phy: Mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ray_cs: mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114948 ("Missing break in switch") Addresses-Coverity-ID: 114949 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rt2x00: rt61pci: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rt2x00: rt2800lib: mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 145198 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rt2x00: rt2500pci: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rt2x00: rt2400pci: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06mwifiex: Mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06prism54: islpci_dev: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114947 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06prism54: isl_ioctl: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06prism54: isl_38xx: Mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114944 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06orinoco_usb: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06iwlegacy: common: mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 201384 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06iwlegacy: 4965-mac: mark expected switch fall-throughGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rtl8xxxu: Fix missing break in switchGustavo A. R. Silva
Add missing break statement in order to prevent the code from falling through to the default case. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rtl8xxxu: Mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1357355 ("Missing break in switch") Addresses-Coverity-ID: 1357378 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rtlwifi: btcoex: remove set but not used variable 'ppsc'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c: In function 'halbtc_leave_lps': drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:295:21: warning: variable 'ppsc' set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c: In function 'halbtc_enter_lps': drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:318:21: warning: variable 'ppsc' set but not used [-Wunused-but-set-variable] It never used since introduction in commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06qtnfmac: fix error handling in control pathSergey Matyukevich
This patch fixes the following warnings: - smatch drivers/net/wireless/quantenna/qtnfmac/commands.c:132 qtnf_cmd_send_with_reply() warn: variable dereferenced before check 'resp' (see line 117) drivers/net/wireless/quantenna/qtnfmac/commands.c:716 qtnf_cmd_get_sta_info() error: uninitialized symbol 'var_resp_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1668 qtnf_cmd_get_mac_info() error: uninitialized symbol 'var_data_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1697 qtnf_cmd_get_hw_info() error: uninitialized symbol 'info_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1753 qtnf_cmd_band_info_get() error: uninitialized symbol 'info_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1782 qtnf_cmd_send_get_phy_params() error: uninitialized symbol 'response_size'. drivers/net/wireless/quantenna/qtnfmac/commands.c:2438 qtnf_cmd_get_chan_stats() error: uninitialized symbol 'var_data_len'. - gcc-8.2.1 drivers/net/wireless/quantenna/qtnfmac/commands.c: In function 'qtnf_cmd_send_with_reply': drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: error: 'resp' may be used uninitialized in this function [-Werror=maybe-uninitialized] Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: fix spelling mistake "Retreiving" -> "Retrieving"Colin Ian King
Trivial fix to spelling mistake in brcmf_err error message. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06qtnfmac: add support for Topaz chipsetsSergey Matyukevich
This patch adds support for QSR1000/QSR2000 family of chipsets to qtnfmac_pcie platform driver. QSR1000/QSR2000 (aka Topaz) is a family of 80MHz, 11ac Wave2, 4x4/2x4/2x2 chips, including single and dual band devices. Depending on specific chip model and firmware in use, either STA or both STA and AP modes are supported. Patch adds Topaz support to qtnfmac_pcie driver. Proper platform bus will be selected on probing based on chip ID. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by: Andrey Shevchenko <ashevchenko@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06qtnfmac_pcie: use single PCIe driver for all platformsIgor Mitsyanko
Single PCIe driver can identify hardware type by reading CHIP ID at probe time and invoking a correct initialization sequence. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06wlcore: Fix the return value in case of error in ↵Christophe JAILLET
'wlcore_vendor_cmd_smart_config_start()' We return 0 unconditionally at the end of 'wlcore_vendor_cmd_smart_config_start()'. However, 'ret' is set to some error codes in several error handling paths and we already return some error codes at the beginning of the function. Return 'ret' instead to propagate the error code. Fixes: 80ff8063e87c ("wlcore: handle smart config vendor commands") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06libertas: remove set but not used variable 'int_type'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/marvell/libertas/if_spi.c: In function 'if_spi_h2c': drivers/net/wireless/marvell/libertas/if_spi.c:799:6: warning: variable 'int_type' set but not used [-Wunused-but-set-variable] It never used since introduction in commit d2b21f191753 ("libertas: if_spi, driver for libertas GSPI devices") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Tested-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06rsi: fix spelling mistake "Initialzing" -> "Initializing"Colin Ian King
Trivial fix to spelling mistake in rsi_dbg debug message Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Fix ccode from EFI nvram when necessaryHans de Goede
In some cases the EFI-var stored nvram contains "ccode=ALL" or "ccode=XV" to specify "worldwide" compatible settings, but these 2 ccode-s do not work properly. I've tested the different known "worldwide" ccode-s used in various nvram sources with the latest firmwares from linux-firmware for various brcmfmac models, here is a simplified (*) table with what each setting results in: ALL: 12-14 disab, U-NII-1, U-NII-2 no-IR/radar, U-NII-3 XV: 12-14 no-IR, disables all 5G channels XY: 12-13 enab, 14 disab, U-NII-1 enab, U-NII-2 no-IR/radar, U-NII-3 disab X2: 12-13 no-IR, 14 dis, U-NII-1 no-IR, U-NII-2 no-IR/radar, U-NII-3 no-IR Where 12,13,14 are 2.4G channels 12-14 and U-NII-1/2/3 are the 3 different 5G channel groups. no-IR is no-Initiate-Radiation, we will never send on these channels without first having received valid wifi traffic there. This immediately shows that both ALL and XV are not as worldwide as we want them to be. ALL causes channels 12 and 13 to not be available and XV causes all 5GHz channels to not be available. Also ALL unconditionally enables the U-NII-1 and U-NII-3 5G groups, while we really should be using no-IR for these. This commit replace XV and ALL with X2, which allows usage of chan 12-13 and 5G channels, but only after receiving valid wifi traffic there first. Note that this configure the firmware's channel limits, the kernels own regulatory restrictions based on e.g. regulatory info received from the access-point, will be applied on top of this. This fixes channels 12+13 not working on the Asus T200TA and the Lenovo Mixx 2 8 and 5G channels not working on the Asus T100HA. This has been tested on the following models: Acer Iconia Tab8 w1-810, Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a Lenovo Mixx 2 8. *) There are some exceptions to this table: 1) On really old firmware e.g. linux-firmware's 2011 brcmfmac4330-sdio.bin ALL really means all, unconditionally enabling everything 2) The exact meaning might be influenced by setting the regrev nvram var. Specifically using ccode=XV + regrev=1 on brcmfmac43241b4 leads to: 12-14 no-ir, U-NII-1 no-ir, U-NII-2 no-ir/radar, U-NII-3 no-ir But only on the brcmfmac43241b4 and not on e.g. the brcmfmac43340 Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Add support for getting nvram contents from EFI variablesHans de Goede
Various X86 laptops with a SDIO attached brcmfmac wifi chip, store the nvram contents in a special EFI variable. This commit adds support for getting nvram directly from this EFI variable, without the user needing to manually copy it. This makes Wifi / Bluetooth work out of the box on these devices instead of requiring manual setup. This has been tested on the following models: Acer Iconia Tab8 w1-810, Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a Lenovo Mixx 2 8. Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Cleanup brcmf_fw_request_done()Hans de Goede
The "cur" variable is now only used for a debug print and we already print the same info from brcmf_fw_complete_request(), so the debug print does not provide any extra info and we can remove it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Set board_type from DMI on x86 based machinesHans de Goede
For x86 based machines, set the board_type used for nvram file selection based on the DMI sys-vendor and product-name strings. Since on some models these strings are too generic, this commit also adds a quirk table overriding the strings for models listed in that table. The board_type setting is used to load the board-specific nvram file with a board-specific name so that we can ship files for each supported board in linux-firmware. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Set board_type used for nvram file selection to machine-compatibleHans de Goede
For of/devicetree using machines, set the board_type used for nvram file selection to the first string listed in the top-level's node compatible string, aka the machine-compatible as used by of_machine_is_compatible(). The board_type setting is used to load the board-specific nvram file with a board-specific name so that we can ship files for each supported board in linux-firmware. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Add support for first trying to get a board specific nvram fileHans de Goede
The nvram files which some brcmfmac chips need are board-specific. To be able to distribute these as part of linux-firmware, so that devices with such a wifi chip will work OOTB, multiple (one per board) versions must co-exist under /lib/firmware. This commit adds support for callers of the brcmfmac/firmware.c code to pass in a board_type parameter through the request structure. If that parameter is set then the code will first try to load chipmodel.board_type.txt before falling back to the old chipmodel.txt name. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Remove recursion from firmware load error handlingHans de Goede
Before this commit brcmf_fw_request_done would call brcmf_fw_request_next_item to load the next item, which on an error would call brcmf_fw_request_done, which if the error is recoverable (*) will then continue calling brcmf_fw_request_next_item for the next item again which on an error will call brcmf_fw_request_done again... This does not blow up because we only have a limited number of items so we never recurse too deep. But the recursion is still quite ugly and frankly is giving me a headache, so lets fix this. This commit fixes this by removing brcmf_fw_request_next_item and by making brcmf_fw_get_firmwares and brcmf_fw_request_done directly call firmware_request_nowait resp. firmware_request themselves. *) brcmf_fw_request_nvram_done fallback path succeeds or BRCMF_FW_REQF_OPTIONAL is set Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Remove firmware-loading code duplicationHans de Goede
brcmf_fw_request_next_item and brcmf_fw_request_done both have identical code to complete the fw-request depending on the item-type. This commit adds a new brcmf_fw_complete_request helper removing this code duplication. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: remove 'experimental' tagLorenzo Bianconi
Remove experimental tag from dynack Kconfig entry since it has been tested on outdoor 25Km links Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: make ewma estimation fasterLorenzo Bianconi
In order to make propagation time estimation faster, use current sample as ewma output value during 'late ack' tracking Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: check da->enabled first in sampling routinesLorenzo Bianconi
Check da->enabled flag first in ath_dynack_sample_tx_ts and ath_dynack_sample_ack_ts routines in order to avoid useless processing Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: move debug log after buffer incrementsLorenzo Bianconi
Move debug log in ath_dynack_sample_tx_ts and ath_dynack_sample_ack_ts after timestamp buffer head/tail increments in order to make debugging more user friendly Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: use authentication messages for 'late' ackLorenzo Bianconi
In order to properly support dynack in ad-hoc mode running wpa_supplicant, take into account authentication frames for 'late ack' detection. This patch has been tested on devices mounted on offshore high-voltage stations connected through ~24Km link Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: fix struct init whitespace in SNOC driverBrian Norris
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: don't assume this is a PCI dev in generic codeBrian Norris
Not all devices using this driver are backed by a PCI device, so it's not fair to assume 'to_pci_dev()' is valid. Fortunately, we only were using this to convert straight back to a bare 'device', which means we were only doing no-op pointer arithmetic, and not actually accessing potentially out-of-bounds memory. But this is still bad practice. Just use 'ar->dev' directly, since that's really all we're looking for. Fixes: 209b2a68de76 ("ath10k: add platform regulatory domain support") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: assign 'n_cipher_suites' for WCN3990Brian Norris
Commit 2ea9f12cefe4 ("ath10k: add new cipher suite support") added a new n_cipher_suites HW param with a fallback value and a warning log. Commit 03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990") later added WCN3990 HW entries, but it missed the n_cipher_suites. Rather than seeing this warning every boot ath10k_snoc 18800000.wifi: invalid hw_params.n_cipher_suites 0 let's provide the appropriate value. Cc: Rakesh Pillai <pillair@qti.qualcomm.com> Cc: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: ath10k_snoc_{read,write}32() should be staticBrian Norris
They're provided as callbacks in ath10k_hif_ops and should be accessed that way, if needed outside of snoc.c, and anyway, they're currently unused outside snoc.c. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: snoc: fix unbalanced clock error handlingBrian Norris
Similar to regulator error handling, we should only start tearing down the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might end up with an unbalanced clock, where we never successfully enabled the clock, but we try to disable it anyway. Fixes: a6a793f98786 ("ath10k: vote for hardware resources for WCN3990") Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: snoc: relax voltage requirementsBrian Norris
I rarely see drivers specify precise voltage requirements like this, but if we really have to...let's at least give a little wiggle room. Board designs (and accompanying device trees) may not provide exactly the voltage listed here, and we shouldn't fail to probe just because of this. Round these ranges down to the nearest volt, and provide a 0.05V margin. The regulator should provide its own supported ranges, which will helpfully intersect with these ranges. I would just as well remove these ranges entirely, but if I understand correctly, there's some reason that QCOM SoC's like to set zero / non-zero voltages. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: snoc: fix unabalanced regulator error handlingBrian Norris
If a regulator fails to set its voltage, we end up with an unbalanced call to regulator_disable(), because the error path starts with the current regulator (which was never enabled). Factor out the "on" function to perform (and unwind if failed) a single regulator at a time, and then main loop (ath10k_snoc_vreg_on()) can just worry about unwinding the regulators that were already enabled. It also helps to factor out the "off" function, to avoid repeating some code here. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath10k: snoc: remove 'wcn3990' from generic resource handlingBrian Norris
ath10k_wcn3990_clk_info and ath10k_wcn3990_vreg_info are not WCN3990-specific structures. They hold generic data. So don't name them with wcn3990 specifics. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2025-07-16 09:58:38 +0000