aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless/broadcom
AgeCommit message (Collapse)AuthorFilesLines
2019-11-20brcmfmac: remove monitor interface when detachingRafał Miłecki1-0/+5
This fixes a minor WARNING in the cfg80211: [ 130.658034] ------------[ cut here ]------------ [ 130.662805] WARNING: CPU: 1 PID: 610 at net/wireless/core.c:954 wiphy_unregister+0xb4/0x198 [cfg80211] Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-11-20brcmfmac: disable PCIe interrupts before bus resetRafał Miłecki1-0/+2
Keeping interrupts on could result in brcmfmac freeing some resources and then IRQ handlers trying to use them. That was obviously a straight path for crashing a kernel. Example: CPU0 CPU1 ---- ---- brcmf_pcie_reset brcmf_pcie_bus_console_read brcmf_detach ... brcmf_fweh_detach brcmf_proto_detach brcmf_pcie_isr_thread ... brcmf_proto_msgbuf_rx_trigger ... drvr->proto->pd brcmf_pcie_release_irq [ 363.789218] Unable to handle kernel NULL pointer dereference at virtual address 00000038 [ 363.797339] pgd = c0004000 [ 363.800050] [00000038] *pgd=00000000 [ 363.803635] Internal error: Oops: 17 [#1] SMP ARM (...) [ 364.029209] Backtrace: [ 364.031725] [<bf243838>] (brcmf_proto_msgbuf_rx_trigger [brcmfmac]) from [<bf2471dc>] (brcmf_pcie_isr_thread+0x228/0x274 [brcmfmac]) [ 364.043662] r7:00000001 r6:c8ca0000 r5:00010000 r4:c7b4f800 Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: [email protected] # v5.2+ Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-11-20brcmfmac: remove set but not used variable 'mpnum','nsp','nmp'zhengbin1-5/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function brcmf_chip_dmp_get_regaddr: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:790:5: warning: variable mpnum set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function brcmf_chip_dmp_erom_scan: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:866:10: warning: variable nsp set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function brcmf_chip_dmp_erom_scan: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:866:5: warning: variable nmp set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <[email protected]> Signed-off-by: zhengbin <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-11-15brcmsmac: remove unnecessary returnEduardo Abinader1-2/+0
Signed-off-by: Eduardo Abinader <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-11-06brcmsmac: remove set but not used variablesYueHaibing1-9/+2
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:841:7: warning: variable free_pdu set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:842:30: warning: variable tx_rts_count set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:842:6: warning: variable tx_rts set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:843:7: warning: variable totlen set but not used [-Wunused-but-set-variable] They are never used, so can be removed. Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-11-05Merge tag 'wireless-drivers-next-2019-11-05' of ↵David S. Miller13-37/+152
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.5 First set of patches for 5.5. The most active driver here clearly is rtw88, lots of patches for it. More quiet on other drivers, smaller fixes and cleanups all over. This pull request also has a trivial conflict, the report and example resolution here: https://lkml.kernel.org/r/[email protected] Major changes: rtw88 * add deep power save support * add mac80211 software tx queue (wake_tx_queue) support * enable hardware rate control * add TX-AMSDU support * add NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 support * add power tracking support * add 802.11ac beamformee support * add set_bitrate_mask support * add phy_info debugfs to show Tx/Rx physical status * add RFE type 3 support for 8822b ath10k * add support for hardware rfkill on devices where firmware supports it rtl8xxxu * add bluetooth co-existence support for single antenna iwlwifi * Revamp the debugging infrastructure ==================== Signed-off-by: David S. Miller <[email protected]>
2019-10-31b43: dma: Fix use true/false for bool type variableSaurav Girepunje1-2/+2
use true/false for bool type variables assignment. Signed-off-by: Saurav Girepunje <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-31b43: main: Fix use true/false for bool typeSaurav Girepunje1-3/+3
use true/false on bool type variable assignment. Signed-off-by: Saurav Girepunje <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-15wireless: Remove call to memset after dma_alloc_coherentFuqian Huang1-2/+0
In commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*"), dma_alloc_coherent has already zeroed the memory. So memset is not needed. Signed-off-by: Fuqian Huang <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-04brcmfmac: add support for SAE authentication offloadChung-Hsien Hsu6-8/+90
The firmware may have SAE authentication code built-in. This is detected by the driver and indicated in the wiphy features flags. User-space can use this flag to determine whether or not to provide the password material for SAE authentication in the nl80211 CONNECT command. Signed-off-by: Chung-Hsien Hsu <[email protected]> Signed-off-by: Chi-Hsien Lin <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-04mac80211: simplify TX aggregation startJohannes Berg1-2/+1
There really is no need to make drivers call the ieee80211_start_tx_ba_cb_irqsafe() function and then schedule the worker if all we want is to set a bit. Add a new return value (that was previously considered invalid) to indicate that the driver is immediately ready for the session, and make drivers use it. The only drivers that remain different are the Intel ones as they need to negotiate more with the firmware. Link: https://lore.kernel.org/r/1570007543-I152912660131cbab2e5d80b4218238c20f8a06e5@changeid Signed-off-by: Johannes Berg <[email protected]>
2019-10-01brcmsmac: remove duplicated if conditionDenis Efremov1-6/+4
The nested 'li_mimo == &locale_bn' check is excessive and always true. Thus it can be safely removed. Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-01brcmfmac: fix suspend/resume when power is cut offAdrian Ratiu1-14/+39
brcmfmac assumed the wifi device always remains powered on and thus hardcoded the MMC_PM_KEEP_POWER flag expecting the wifi device to remain on even during suspend/resume cycles. This is not always the case, some appliances cut power to everything connected via SDIO for efficiency reasons and this leads to wifi not being usable after coming out of suspend because the device was not correctly reinitialized. So we check for the keep_power capability and if it's not present then we remove the device and probe it again during resume to mirror what's happening in hardware and ensure correct reinitialization in the case when MMC_PM_KEEP_POWER is not supported. Suggested-by: Gustavo Padovan <[email protected]> Signed-off-by: Adrian Ratiu <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-01brcmfmac: don't WARN when there are no requestsAdrian Ratiu1-0/+4
When n_reqs == 0 there is nothing to do so it doesn't make sense to search for requests and issue a warning because none is found. Signed-off-by: Martyn Welch <[email protected]> Signed-off-by: Adrian Ratiu <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-01brcmsmac: remove a useless testChristophe JAILLET1-2/+1
'pih' is known to be non-NULL at this point, so the test can be removed. Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-10-01brcmfmac: send port authorized event for FT-802.1XChung-Hsien Hsu2-0/+9
With FT-802.1X, driver should send a port authorized event right after sending a roamed event. It is used to indicate that a new AP is already authorized so 802.1X is not required. Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Chung-Hsien Hsu <[email protected]> Signed-off-by: Chi-Hsien Lin <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-13brcmsmac: Use DIV_ROUND_CLOSEST directly to make it readablezhong jiang1-7/+7
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. Signed-off-by: zhong jiang <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-13brcmfmac: don't realloc wiphy during PCIe resetRafał Miłecki1-4/+4
Providing a new wiphy on every PCIe reset was confusing and was causing configuration problems for some users (supplicant and authenticators). Sticking to the existing wiphy should make error recovery much simpler and more reliable. Signed-off-by: Rafał Miłecki <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-13brcmfmac: split brcmf_attach() and brcmf_detach() functionsRafał Miłecki5-19/+80
Move code allocating/freeing wiphy out of above functions. This will allow reinitializing the driver (e.g. on some error) without allocating a new wiphy. Signed-off-by: Rafał Miłecki <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-13brcmfmac: move "cfg80211_ops" pointer to another structRafał Miłecki4-5/+7
This moves "ops" pointer from "struct brcmf_cfg80211_info" to the "struct brcmf_pub". This movement makes it possible to allocate wiphy without attaching cfg80211 (brcmf_cfg80211_attach()). It's required for later separation of wiphy allocation and driver initialization. While at it fix also an unlikely memory leak in the brcmf_attach(). Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-06brcmfmac: use %*ph to print small bufferAndy Shevchenko1-12/+6
Use %*ph format to print small buffer as hex string. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-06brcmfmac: add "reset" debugfs entry for testing resetRafał Miłecki1-0/+25
This is a trivial debugfs entry for triggering reset just like in case of firmware crash. It works by writing 1 to it: echo 1 > reset Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-06brcmfmac: add stub version of brcmf_debugfs_get_devdir()Rafał Miłecki1-0/+4
In case of compiling driver without DEBUG expose a stub function to make writing debug code much simpler (no extra conditions). This will allow e.g. using debugfs_create_file() without any magic if or #ifdef. Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-03brcmfmac: get chip's default RAM info during PCIe setupRafał Miłecki3-2/+11
Getting RAM info just once per driver's lifetime (during chip recognition) is not enough as it may get adjusted later (depending on the used firmware). Subsequent inits may load different firmwares so a full RAM recognition is required on every PCIe setup. This is especially important since implementing hardware reset on a firmware crash. Moreover calling brcmf_chip_get_raminfo() makes sure that RAM core is up. It's important as having BCMA_CORE_SYS_MEM down on BCM4366 was resulting in firmware failing to initialize and following error: [ 65.657546] brcmfmac 0000:01:00.0: brcmf_pcie_download_fw_nvram: Invalid shared RAM address 0x04000001 This change makes brcmf_chip_get_raminfo() call during chip recognition redundant for PCIe devices but SDIO and USB still need it and it's a very small overhead anyway. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-03brcmfmac: replace strncpy() by strscpy()Xulin Sun1-3/+1
The strncpy() may truncate the copied string, replace it by the safer strscpy(). To avoid below compile warning with gcc 8.2: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie': drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2: warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation] strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Xulin Sun <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-03brcmfmac: remove redundant assignment to pointer hashColin Ian King1-1/+0
The pointer hash is being initialized with a value that is never read and is being re-assigned a little later on. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-09-03brcm80211: Avoid possible null-pointer dereferences in wlc_phy_radio_init_2056()Jia-Ju Bai1-1/+1
In wlc_phy_radio_init_2056(), regs_SYN_2056_ptr, regs_TX_2056_ptr and regs_RX_2056_ptr may be not assigned, and thus they are still NULL. Then, they are used on lines 20042-20050: wlc_phy_init_radio_regs(pi, regs_SYN_2056_ptr, (u16) RADIO_2056_SYN); wlc_phy_init_radio_regs(pi, regs_TX_2056_ptr, (u16) RADIO_2056_TX0); wlc_phy_init_radio_regs(pi, regs_TX_2056_ptr, (u16) RADIO_2056_TX1); wlc_phy_init_radio_regs(pi, regs_RX_2056_ptr, (u16) RADIO_2056_RX0); wlc_phy_init_radio_regs(pi, regs_RX_2056_ptr, (u16) RADIO_2056_RX1); Thus, possible null-pointer dereferences may occur. To avoid these bugs, when these variables are not assigned, wlc_phy_radio_init_2056() directly returns. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-08-06b43legacy: Remove pointless cond_resched() wrapperThomas Gleixner1-16/+5
cond_resched() can be used unconditionally. If CONFIG_PREEMPT is set, it becomes a NOP scheduler wise. Also the B43_BUG_ON() in that wrapper is a homebrewn variant of __might_sleep() which is part of cond_resched() already. Remove the cruft and invoke cond_resched() directly. Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Larry Finger <[email protected]> Tested-by: Larry Finger <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-08-06brcmsmac: remove three set but not used variablesYueHaibing1-13/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c: In function 'brcms_c_set_gmode': drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5257:7: warning: variable 'preamble_restrict' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5256:6: warning: variable 'preamble' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5251:7: warning: variable 'shortslot_restrict' set but not used [-Wunused-but-set-variable] They are never used so can be removed. Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-08-06brcmfmac: remove set but not used variable 'dtim_period'YueHaibing1-7/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function brcmf_update_bss_info: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2962:5: warning: variable dtim_period set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function brcmf_update_bss_info: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2961:6: warning: variable beacon_interval set but not used [-Wunused-but-set-variable] They are never used so can be removed. Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: don't net_ratelimit() CONSOLE messages on firmware crashRafał Miłecki1-1/+2
Firmware crash is a pretty rare event and can't happen too frequently as it has to be followed by a hardware reinitialization and config reload. It should be safe to don't use net_ratelimit() when it happens. For reporting & debugging purposes it's important to provide a complete log as the last lines are actually the most important. This change modifies brcmfmac to print all messages in an unlimited way in that specific case. With this change there should be finally a backtrace of firmware finally visible after a crash. Signed-off-by: Rafał Miłecki <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: remove unnecessary strlcpy() upon obtaining "ver" iovarArend van Spriel1-1/+0
Recently a strcpy() was replaced by strlcpy(). However, the strcpy() was not needed in the first place. So removing that line of code. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: simply remove flowring if bus is downArend van Spriel1-0/+7
When the bus is down, eg. due to rmmod, there is no need to attempt to inform firmware about it. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: avoid firmware commands when bus is downArend van Spriel1-10/+13
Upon rmmod a few attempts are made to inform firmware, but there is no point as the bus is down and these will fail. Avoid them to keep the logs clean. Reported-by: Stefan Wahren <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: clear events in brcmf_fweh_detach() will always failArend van Spriel1-9/+0
Clearing firmware events in brcmf_fweh_detach() is always failing because it is called only upon driver remove and communication with firmware is no longer possible. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: avoid firmware command in brcmf_netdev_open() when bus is downArend van Spriel1-1/+2
No point in sending a firmware command when bus is down so make it conditional checking the state. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: change the order of things in brcmf_detach()Arend van Spriel1-13/+14
When brcmf_detach() from the bus layer upon rmmod we can no longer communicate. Hence we will set the bus state to DOWN and cleanup the event and protocol layer. The network interfaces need to be deleted before brcmf_cfg80211_detach() because the latter does the wiphy_unregister() which issues a warning if there are still network devices linked to the wiphy instance. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Tested-by: Rafał Miłecki <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"Arend van Spriel7-40/+13
This reverts commit 5cdb0ef6144f47440850553579aa923c20a63f23. Subsequent changes make rework the driver code fixing the issue differently. Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: allow 160MHz in custom regulatory rulesArend van Spriel1-2/+2
The driver has custom regulatory rules which had maximum bandwidth for 5GHz channels set to 80MHz. As a consequence the driver can not use 160MHz in AP mode even when the device supports it. So relax the rules allowing 160MHz. After wiphy_register() the channel flags are updated according what the device actually supports. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: enable DFS_OFFLOAD extended feature if supportedArend van Spriel3-1/+9
If the firmware supports 802.11h and the device can operate in 5GHz band we can enable DFS_OFFLOAD extended feature. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-24brcmfmac: add 160MHz in chandef_to_chanspec()Arend van Spriel1-1/+20
The function chandef_to_chanspec() was not handling 160MHz bandwidth resulting in wrong encoding of the channel. That resulting in firmware rejecting the provided channel specification. Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-07-20wireless: fix nl80211 vendor commandsJohannes Berg1-0/+1
In my previous commit to validate a policy I neglected to actually add one to the few drivers using vendor commands, fix that now. Reported-by: Tony Lindgren <[email protected]> Tested-by: Tony Lindgren <[email protected]> Fixes: 901bb9891855 ("nl80211: require and validate vendor command policy") Signed-off-by: Johannes Berg <[email protected]>
2019-06-27b43: simplify engine type / DMA mask selectionChristoph Hellwig1-22/+6
Return the engine type from the function looking at the registers, and just derive the DMA mask from that in the one place we care. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-06-27b43: remove b43_dma_set_maskChristoph Hellwig1-38/+5
These days drivers are not required to fallback to smaller DMA masks, but can just set the largest mask they support, removing the need for this trial and error logic. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-06-27b43legacy: simplify engine type / DMA mask selectionChristoph Hellwig1-17/+3
Return the engine type from the function looking at the registers, and just derive the DMA mask from that in the one place we care. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-06-27b43legacy: remove b43legacy_dma_set_maskChristoph Hellwig1-38/+1
These days drivers are not required to fallback to smaller DMA masks, but can just set the largest mask they support, removing the need for this trial and error logic. Signed-off-by: Christoph Hellwig <[email protected]> Tested-by: Larry Finger <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-06-26Merge tag 'wireless-drivers-next-for-davem-2019-06-26' of ↵David S. Miller81-1004/+153
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valu says: ==================== wireless-drivers-next patches for 5.3 First set of patches for 5.3, but not that many patches this time. This pull request fails to compile with the tip tree due to ktime_get_boot_ns() API changes there. It should be easy for Linus to fix it in p54 driver once he pulls this, an example resolution here: https://lkml.kernel.org/r/[email protected] Major changes: airo * switch to use skcipher interface p54 * support boottime in scan results rtw88 * add fast xmit support * add random mac address on scan support rt2x00 * add software watchdog to detect hangs, it's disabled by default ==================== Signed-off-by: David S. Miller <[email protected]>
2019-06-18brcmfmac: sdio: Don't tune while the card is offDouglas Anderson1-0/+7
When Broadcom SDIO cards are idled they go to sleep and a whole separate subsystem takes over their SDIO communication. This is the Always-On-Subsystem (AOS) and it can't handle tuning requests. Specifically, as tested on rk3288-veyron-minnie (which reports having BCM4354/1 in dmesg), if I force a retune in brcmf_sdio_kso_control() when "on = 1" (aka we're transition from sleep to wake) by whacking: bus->sdiodev->func1->card->host->need_retune = 1 ...then I can often see tuning fail. In this case dw_mmc reports "All phases bad!"). Note that I don't get 100% failure, presumably because sometimes the card itself has already transitioned away from the AOS itself by the time we try to wake it up. If I force retuning when "on = 0" (AKA force retuning right before sending the command to go to sleep) then retuning is always OK. NOTE: we need _both_ this patch and the patch to avoid triggering tuning due to CRC errors in the sleep/wake transition, AKA ("brcmfmac: sdio: Disable auto-tuning around commands expected to fail"). Though both patches handle issues with Broadcom's AOS, the problems are distinct: 1. We want to defer (but not ignore) asynchronous (like timer-requested) tuning requests till the card is awake. However, we want to ignore CRC errors during the transition, we don't want to queue deferred tuning request. 2. You could imagine that the AOS could implement retuning but we could still get errors while transitioning in and out of the AOS. Similarly you could imagine a seamless transition into and out of the AOS (with no CRC errors) even if the AOS couldn't handle tuning. ALSO NOTE: presumably there is never a desperate need to retune in order to wake up the card, since doing so is impossible. Luckily the only way the card can get into sleep state is if we had a good enough tuning to send it the command to put it into sleep, so presumably that "good enough" tuning is enough to wake us up, at least with a few retries. Cc: [email protected] #v4.18+ Signed-off-by: Douglas Anderson <[email protected]> Acked-by: Adrian Hunter <[email protected]> Reviewed-by: Arend van Spriel <[email protected]> Acked-by: Kalle Valo <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2019-06-18brcmfmac: sdio: Disable auto-tuning around commands expected to failDouglas Anderson1-0/+4
There are certain cases, notably when transitioning between sleep and active state, when Broadcom SDIO WiFi cards will produce errors on the SDIO bus. This is evident from the source code where you can see that we try commands in a loop until we either get success or we've tried too many times. The comment in the code reinforces this by saying "just one write attempt may fail" Unfortunately these failures sometimes end up causing an "-EILSEQ" back to the core which triggers a retuning of the SDIO card and that blocks all traffic to the card until it's done. Let's disable retuning around the commands we expect might fail. Cc: [email protected] #v4.18+ Signed-off-by: Douglas Anderson <[email protected]> Acked-by: Adrian Hunter <[email protected]> Reviewed-by: Arend van Spriel <[email protected]> Acked-by: Kalle Valo <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2019-06-18Revert "brcmfmac: disable command decode in sdio_aos"Douglas Anderson1-5/+1
This reverts commit 29f6589140a10ece8c1d73f58043ea5b3473ab3e. After that patch landed I find that my kernel log on rk3288-veyron-minnie and rk3288-veyron-speedy is filled with: brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110 This seems to happen every time the Broadcom WiFi transitions out of sleep mode. Reverting the commit fixes the problem for me, so that's what this patch does. Note that, in general, the justification in the original commit seemed a little weak. It looked like someone was testing on a SD card controller that would sometimes die if there were CRC errors on the bus. This used to happen back in early days of dw_mmc (the controller on my boards), but we fixed it. Disabling a feature on all boards just because one SD card controller is broken seems bad. Fixes: 29f6589140a1 ("brcmfmac: disable command decode in sdio_aos") Cc: Wright Feng <[email protected]> Cc: Double Lo <[email protected]> Cc: Madhan Mohan R <[email protected]> Cc: Chi-Hsien Lin <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Cc: [email protected] Acked-by: Kalle Valo <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.