summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/broadcom
AgeCommit message (Collapse)Author
2019-02-19brcmfmac: improve code handling bandwidth of firmware reported channelsRafał Miłecki
1) Use switch to simplify/improve the code & avoid some duplication 2) Add warning for unsupported values Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: print firmware reported ring status errorsRafał Miłecki
Firmware is capable of reporting ring status. It's used e.g. to signal some problem with a specific ring setup. This patch adds support for printing ring & error number which may be useful for debugging setup issues. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: use chipname in brcmf_fw_alloc_request() for error path as wellArend van Spriel
The local variable chipname is string representation of chip id and revision which is printed in the good flow of brcmf_fw_alloc_request(). Also use it for the error path, ie. for unknown/unsupported devices. Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: check and dump trap info during sdio probeArend van Spriel
When the firmware crashes during the probe sequence we provide little information on what really failed. This patch checks the sdpcm shared location and show the trap information if a firmware trap has happened. Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: disable MBSS feature for bcm4330 deviceArend van Spriel
The MBSS feature was already disabled for bcm43362 as it resulted in a beacon with BRCM_TEST_SSID regardless user configuration in hostapd. Now the same has been reported for bcm4330 so disable the feature for this device as well. Reported-by: Russell King <linux@armlinux.org.uk> Tested-by: Christopher Martin <chrsmrtn@gmail.com> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: create debugfs files for bus-specific layerArend van Spriel
Since we moved the drivers debugfs directory under ieee80211 debugfs the debugfs entries need to be added after wiphy_register() has been called. For most part that has been done accordingly, but for the debugfs entries added by SDIO it was not and failed silently. This patch fixes that by adding a bus-layer callback for it. Fixes: 856d5a011c86 ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()") Reported-by: Russel King <linux@armlinux.org.uk> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: add subtype check for event handling in data pathArend van Spriel
For USB there is no separate channel being used to pass events from firmware to the host driver and as such are passed over the data path. In order to detect mock event messages an additional check is needed on event subtype. This check is added conditionally using unlikely() keyword. Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19brcmfmac: assure SSID length from firmware is limitedArend van Spriel
The SSID length as received from firmware should not exceed IEEE80211_MAX_SSID_LEN as that would result in heap overflow. Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-08brcmfmac: support monitor frames with the hardware/ucode headerRafał Miłecki
So far there were two monitor frame formats: 1) 802.11 frames (with frame (sub)type & all addresses) 2) 802.11 frames with the radiotap header Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in discovering a new format being used. It seems (almost?) identical to the one known from ucode used in SoftMAC devices which is most likely the same codebase anyway. While new firmwares will /announce/ radiotap header support using the "rtap" fw capability string it seems no string was added for the new ucode header format. All above means that: 1) We need new format support when dealing with a received frame 2) A new feature bit & mapping quirks have to be added manually As for now only an empty radiotap is being created. Adding support for extracting some info (band, channel, signal, etc.) is planned for the future. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-08brcmfmac: fix typosMatteo Croce
Fix spelling mistakes in brcmfmac: "lenght" -> "length". The typos are also in the special comment blocks which translates to documentation. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-08brcmfmac: add bphy_err() and use it in the cfg80211.cRafał Miłecki
This new macro uses wiphy_err() which: 1) Should be the best choice with wiphy already created 2) Uses dev_err() which allows identifying error-affected device Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-08brcmfmac: pass bus to the __brcmf_err() in pcie.cRafał Miłecki
This enables dev_err() usage (instead of pr_err()) in the __brcmf_err(). It makes error messages more meaningful and is important for debugging errors/bugs on systems with multiple brcmfmac supported devices. All bus files should follow & get updated similarly (soon). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-08brcmfmac: modify __brcmf_err() to take bus as a parameterRafał Miłecki
So far __brcmf_err() was using pr_err() which didn't allow identifying device that was affected by an error. It's crucial for systems with more than 1 device supported by brcmfmac (a common case for home routers). This change allows passing struct brcmf_bus to the __brcmf_err(). That struct has been agreed to be the most common one. It allows accessing struct device easily & using dev_err() printing helper. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-06Merge tag 'wireless-drivers-next-for-davem-2019-02-06' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.1 First set of patches for 5.1. Lots of new features in various drivers but nothing really special standing out. Major changes: brcmfmac * DMI nvram filename quirk for PoV TAB-P1006W-232 tablet rsi * support for hardware scan offload iwlwifi * support for Target Wakeup Time (TWT) -- a feature that allows the AP to specify when individual stations can access the medium * support for mac80211 AMSDU handling * some new PCI IDs * relicense the pcie submodule to dual GPL/BSD * reworked the TOF/CSI (channel estimation matrix) implementation * Some product name updates in the human-readable strings mt76 * energy detect regulatory compliance fixes * preparation for MT7603 support * channel switch announcement support mwifiex * support for sd8977 chipset qtnfmac * support for 4addr mode * convert to SPDX license identifiers ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-01wireless: prefix header search paths with $(srctree)/Masahiro Yamada
Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter"). I also removed one header search path in: drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile I was able to compile without it. [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-01brcmsmac: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Cc: Wright Feng <wright.feng@cypress.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: brcm80211-dev-list@cypress.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Arend van Spriel Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-01b43legacy: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: linux-wireless@vger.kernel.org Cc: b43-dev@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-01b43: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: linux-wireless@vger.kernel.org Cc: b43-dev@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-01wireless: remove unneeded semicolonYueHaibing
remove unneeded semicolon Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Acked-by: Steve deRosier <derosier@cal-sierra.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10brcmfmac: Use firmware_request_nowarn for the clm_blobHans de Goede
The linux-firmware brcmfmac firmware files contain an embedded table with per country allowed channels and strength info. For recent hardware these versions of the firmware are specially build for linux-firmware, the firmware files directly available from Cypress rely on a separate clm_blob file for this info. For some unknown reason Cypress refuses to provide the standard firmware files + clm_blob files it uses elsewhere for inclusion into linux-firmware, instead relying on these special builds with the clm_blob info embedded. This means that the linux-firmware firmware versions often lag behind, but I digress. The brcmfmac driver does support the separate clm_blob file and always tries to load this. Currently we use request_firmware for this. This means that on any standard install, using the standard combo of linux-kernel + linux-firmware, we will get a warning: "Direct firmware load for ... failed with error -2" On top of this, brcmfmac itself prints: "no clm_blob available (err=-2), device may have limited channels available". This commit switches to firmware_request_nowarn, fixing almost any brcmfmac device logging the warning (it leaves the brcmfmac info message in place). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10brcmfmac: fix system warning message during wowl suspendLo-Hsiang Lo
There is a system warning message, warn_slowpath-fmt, during suspend while using supplicant join AP and enable wowl feature by IW command. It's caused by brcmf_pno_remove_request path can't find the reqid. This fix will not go to remove pno request function if there is no pno scan. Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Lo-Hsiang Lo <double.lo@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10brcmfmac: add a check for the status of usb_registerKangjie Lu
usb_register() may fail, so let's check its status and issue an error message if it fails. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10brcmfmac: Add DMI nvram filename quirk for PoV TAB-P1006W-232 tabletHans de Goede
The Point of View TAB-P1006W-232 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: brcmfmac43340-sdio.Insyde-BayTrail.txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the PoV TAB-P1006W-232 tablet. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10brcmsmac: remove set but not used variables 'phybw40, maxtargetpwr'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:1202:5: warning: variable 'phybw40' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4625:5: warning: variable 'phybw40' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4834:5: warning: variable 'phybw40' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:3085:17: warning: variable 'maxtargetpwr' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4215:17: warning: variable 'maxtargetpwr' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-08cross-tree: phase out dma_zalloc_coherent()Luis Chamberlain
We already need to zero out memory for dma_alloc_coherent(), as such using dma_zalloc_coherent() is superflous. Phase it out. This change was generated with the following Coccinelle SmPL patch: @ replace_dma_zalloc_coherent @ expression dev, size, data, handle, flags; @@ -dma_zalloc_coherent(dev, size, handle, flags) +dma_alloc_coherent(dev, size, handle, flags) Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> [hch: re-ran the script on the latest tree] Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-12-20brcmfmac: Fix access point modeStefan Wahren
Since commit 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag") the Raspberry Pi 3 A+ (BCM43455) isn't able to operate in AP mode with hostapd (device_ap_sme=1 use_monitor=0): brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -52 So add the missing mgmt_stypes for AP mode to fix this. Fixes: 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag") Suggested-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-20brcmfmac: fix roamoff=1 modparamStijn Tintel
When the update_connect_param callback is set, nl80211 expects the flag WIPHY_FLAG_SUPPORTS_FW_ROAM to be set as well. However, this flag is only set when modparam roamoff=0, while the callback is set unconditionally. Since commit 7f9a3e150ec7 this causes a warning in wiphy_register, which breaks brcmfmac. Disable the update_connect_param callback when roamoff=0 to fix this. Fixes: 7f9a3e150ec7 ("nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS") Cc: Stable <stable@vger.kernel.org> # 4.19+ Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13b43: remove set but not used variables 'tx_pwr_state,tmp2'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/b43/phy_n.c: In function 'b43_nphy_op_recalc_txpower': drivers/net/wireless/broadcom/b43/phy_n.c:5898:7: warning: variable 'tx_pwr_state' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/b43/phy_n.c:6047:20: warning: variable 'tmp2' set but not used [-Wunused-but-set-variable] 'tx_pwr_state' never used since introduction in commit 8615eb2870f1 ("b43: N-PHY: support setting custom TX power") 'tmp2' not used any more since commit c002831a07dd ("b43: N-PHY: use helper for checking IPA") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: fix false-positive -Wmaybe-unintialized warningArnd Bergmann
When CONFIG_NO_AUTO_INLINE is set, we get a false-postive warning for the brcmf_fw_request_nvram_done() function, after gcc figures out that brcmf_fw_nvram_from_efi() might not set the 'data_len' variable, but fails to notice that it always returns NULL: drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function 'brcmf_fw_request_nvram_done': drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:560:11: error: 'data_len' may be used uninitialized in this function [-Werror=maybe-uninitialized] Mark it 'inline' to force gcc to understand this. Fixes: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: disable command decode in sdio_aosWright Feng
AOS is a part of the SDIOD core that becomes active when the rest of SDIOD is sleeping to keep SDIO bus alive responding to reduced set of commands. Transaction between AOS and SDIOD is not protected, and if cmd 52 is received in AOS and in the middle of response state changed from AOS to SDIOD, response is corrupted and it causes to SDIO Host controller to hang. Command decode for below chips are disabled in this commit: - 4339 - 4345 - 4354 - 4373 Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Double Lo <double.lo@cypress.com> Signed-off-by: Madhan Mohan R <madhanmohan.r@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: 4373 save-restore supportChi-Hsien Lin
Use chipcommon sr_control0 register to check 4373 sr support. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: update 43012 F2 watermark setting to fix DMA Error during UDP RX ↵Naveen Gupta
Traffic The number of words that the read FIFO has to contain except the end of frame before sends data back to the host. Max watermark = (512B - 2* (BurstLength))/4 = (512 - 128)/4 = 384/4 = 0x60 so if burst length (i.e. BurstLength = 64) is increased, watermark has to be reduced. This is the optimal setting for this chip. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Naveen Gupta <naveen.gupta@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: allow GCI core enumurationChi-Hsien Lin
GCI core is needed for ULP operation. Allow GCI core enumuration with below changes: - Allow GCI to be added to core list even when it doesn't have a wrapper. - Allow 8K address space size. - Don't overwrite the address value when an additional size descriptor is in place. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: add support for CYW43012 SDIO chipsetChi-Hsien Lin
CYW43012 is a 1x1 802.11a/b/g/n Dual-Band HT20, 256-QAM/Turbo QAM. It is an Ultra Low Power WLAN+BT combo chip. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Praveen Babu C <praveen.chandran@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: set SDIO F1 MesBusyCtrl for CYW4373Madhan Mohan R
Along with F2 watermark (existing) configuration, F1 MesBusyCtrl should be enabled & sdio device RX FIFO watermark should be configured to avoid overflow errors. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Madhan Mohan R <madhanmohan.r@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: set F2 watermark to 256 for 4373Wright Feng
We got SDIO_CRC_ERROR with 4373 on SDR104 when doing bi-directional throughput test. Enable watermark to 256 to guarantee the operation stability. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: add 4354 raw pcie device idWinnie Chang
Add the raw 4354 PCIe device ID for unprogrammed Cypress boards. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Winnie Chang <winnie.chang@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: handle compressed tx status signalChung-Hsien Hsu
Firmware inform the driver about tx status by normal tx status signal or compressed tx status signal. This patch adds support to handle the compressed tx status signal. Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Wright Feng <wright.feng@cypress.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: enable frameburst mode in default firmware settingWright Feng
The frameburst feature can enable per-packet framebursting in firmware side and get higher TX throughput in High Throughput(HT) mode. To enhance TX throughput, we enable frameburst mode in default firmware setting. Signed-off-by: Wright Feng <wright.feng@cypress.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-13brcmfmac: add credit numbers updating supportWright Feng
The credit numbers are static and tunable per chip in firmware side. However the credit number may be changed that is based on packet pool length and will send BRCMF_E_FIFO_CREDIT_MAP event to notify host driver updates the credit numbers during interface up. The purpose of this patch is making host driver has ability of updating the credit numbers when receiving the BRCMF_E_FIFO_CREDIT_MAP event. Signed-off-by: Wright Feng <wright.feng@cypress.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-03Merge tag 'wireless-drivers-next-for-davem-2018-11-30' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.21 First set of patches for 4.21. Most notable here is support for Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide nvram files for brcmfmac. Major changes: brcmfmac * add support for first trying to get a board specific nvram file * add support for getting nvram contents from EFI variables qtnfmac * use single PCIe driver for all platforms and rename Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE * add support for QSR1000/QSR2000 (Topaz) family of chipsets ath10k * add support for WCN3990 firmware crash recovery * add firmware memory dump support for QCA4019 wil6210 * add firmware error recovery while in AP mode ath9k * remove experimental notice from dynack feature iwlwifi * PCI IDs for some new 9000-series cards * improve antenna usage on connection problems * new firmware debugging infrastructure * some more work on 802.11ax * improve support for multiple RF modules with 22000 devices cordic * move cordic macros and defines to a public header file * convert brcmsmac and b43 to fully use cordic library ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-29brcmfmac: Fix out of bounds memory access during fw loadLyude Paul
I ended up tracking down some rather nasty issues with f2fs (and other filesystem modules) constantly crashing on my kernel down to a combination of out of bounds memory accesses, one of which was coming from brcmfmac during module load: [ 30.891382] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [ 30.894437] ================================================================== [ 30.901581] BUG: KASAN: global-out-of-bounds in brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac] [ 30.909935] Read of size 1 at addr ffff2000024865df by task kworker/6:2/387 [ 30.916805] [ 30.918261] CPU: 6 PID: 387 Comm: kworker/6:2 Tainted: G O 4.20.0-rc3Lyude-Test+ #19 [ 30.927251] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018 [ 30.935964] Workqueue: events brcmf_driver_register [brcmfmac] [ 30.941641] Call trace: [ 30.944058] dump_backtrace+0x0/0x3e8 [ 30.947676] show_stack+0x14/0x20 [ 30.950968] dump_stack+0x130/0x1c4 [ 30.954406] print_address_description+0x60/0x25c [ 30.959066] kasan_report+0x1b4/0x368 [ 30.962683] __asan_report_load1_noabort+0x18/0x20 [ 30.967547] brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac] [ 30.967639] brcmf_sdio_probe+0x163c/0x2050 [brcmfmac] [ 30.978035] brcmf_ops_sdio_probe+0x598/0xa08 [brcmfmac] [ 30.983254] sdio_bus_probe+0x190/0x398 [ 30.983270] really_probe+0x2a0/0xa70 [ 30.983296] driver_probe_device+0x1b4/0x2d8 [ 30.994901] __driver_attach+0x200/0x280 [ 30.994914] bus_for_each_dev+0x10c/0x1a8 [ 30.994925] driver_attach+0x38/0x50 [ 30.994935] bus_add_driver+0x330/0x608 [ 30.994953] driver_register+0x140/0x388 [ 31.013965] sdio_register_driver+0x74/0xa0 [ 31.014076] brcmf_sdio_register+0x14/0x60 [brcmfmac] [ 31.023177] brcmf_driver_register+0xc/0x18 [brcmfmac] [ 31.023209] process_one_work+0x654/0x1080 [ 31.032266] worker_thread+0x4f0/0x1308 [ 31.032286] kthread+0x2a8/0x320 [ 31.039254] ret_from_fork+0x10/0x1c [ 31.039269] [ 31.044226] The buggy address belongs to the variable: [ 31.044351] brcmf_firmware_path+0x11f/0xfffffffffffd3b40 [brcmfmac] [ 31.055601] [ 31.057031] Memory state around the buggy address: [ 31.061800] ffff200002486480: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 [ 31.068983] ffff200002486500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 31.068993] >ffff200002486580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 [ 31.068999] ^ [ 31.069017] ffff200002486600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 31.096521] ffff200002486680: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa [ 31.096528] ================================================================== [ 31.096533] Disabling lock debugging due to kernel taint It appears that when trying to determine the length of the string in the alternate firmware path, we make the mistake of not handling the case where the firmware path is empty correctly. Since strlen(mp_path) can return 0, we'll end up accessing mp_path[-1] when the firmware_path isn't provided through the module arguments. So, fix this by just setting the end char to '\0' by default, and only changing it if we have a non-zero length. Additionally, use strnlen() with BRCMF_FW_ALTPATH_LEN instead of strlen() just to be extra safe. Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function") Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Arend Van Spriel <arend.vanspriel@broadcom.com> Cc: Himanshu Jha <himanshujha199640@gmail.com> Cc: Dan Haab <dhaab@luxul.com> Cc: Jia-Shyr Chuang <saint.chuang@cypress.com> Cc: Ian Molton <ian@mnementh.co.uk> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29brcmfmac: Call brcmf_dmi_probe before brcmf_of_probeHans de Goede
ARM systems with UEFI may have both devicetree (of) and DMI data in this case we end up setting brcmf_mp_device.board_type twice. In this case we should prefer the devicetree data, because: 1) The devicerree data is more reliable 2) Some ARM systems (e.g. the Raspberry Pi 3 models) support both UEFI and classic uboot booting, the devicetree data is always there, so using it makes sure we ask for the same nvram file independent of how we booted. This commit moves the brcmf_dmi_probe call to before the brcmf_of_probe call, so that the latter can override the value of the first if both are set. Fixes: bd1e82bb420a ("brcmfmac: Set board_type from DMI on x86 based ...") Cc: Peter Robinson <pbrobinson@gmail.com> Tested-and-reported-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29brcmfmac: support STA info struct v7Dan Haab
The newest firmwares provide STA info using v7 of the struct. As v7 isn't backward compatible, a union is needed. Even though brcmfmac does not use any of the new info it's important to provide the proper struct buffer. Without this change new firmwares will fallback to the very limited v3 instead of something in between such as v4. Signed-off-by: Dan Haab <dan.haab@luxul.com> Reviewed-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29b43: Use cordic algorithm from kernel libraryPriit Laes
Kernel library has a common cordic algorithm which is identical to internally implemented one, so use it and drop the duplicate implementation. Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29b43: Fix error in cordic routineLarry Finger
The cordic routine for calculating sines and cosines that was added in commit 6f98e62a9f1b ("b43: update cordic code to match current specs") contains an error whereby a quantity declared u32 can in fact go negative. This problem was detected by Priit Laes who is switching b43 to use the routine in the library functions of the kernel. Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)") Reported-by: Priit Laes <plaes@plaes.org> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Stable <stable@vger.kernel.org> # 2.6.34 Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29brcmsmac: Use cordic-related macros from common cordic libraryPriit Laes
Current driver includes macro that is available from general cordic library. Use that and drop unused duplicate and unneeded internal definitions. Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2018-11-16brcmfmac: fix reporting support for 160 MHz channelsRafał Miłecki
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's important to provide valid & complete info about supported bands for each channel. By default no support for 160 MHz should be assumed unless firmware reports it for a given channel later. This fixes info passed to the userspace. Without that change userspace could try to use invalid channel and fail to start an interface. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-10brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw.David S. Miller
Instead of direct SKB list pointer accesses. The loops in this function had to be rewritten to accommodate this more easily. The first loop iterates now over the target list in the outer loop, and triggers an mmc data operation when the per-operation limits are hit. Then after the loops, if we have any residue, we trigger the last and final operation. For the page aligned workaround, where we have to copy the read data back into the original list of SKBs, we use a two-tiered loop. The outer loop stays the same and iterates over pktlist, and then we have an inner loop which uses skb_peek_next(). The break logic has been simplified because we know that the aggregate length of the SKBs in the source and destination lists are the same. This change also ends up fixing a bug, having to do with the maintainance of the seg_sz variable and how it drove the outermost loop. It begins as: seg_sz = target_list->qlen; ie. the number of packets in the target_list queue. The loop structure was then: while (seq_sz) { ... while (not at end of target_list) { ... sg_cnt++ ... } ... seg_sz -= sg_cnt; The assumption built into that last statement is that sg_cnt counts how many packets from target_list have been fully processed by the inner loop. But this not true. If we hit one of the limits, such as the max segment size or the max request size, we will break and copy a partial packet then contine back up to the top of the outermost loop. With the new loops we don't have this problem as we don't guard the loop exit with a packet count, but instead use the progression of the pkt_next SKB through the list to the end. The general structure is: sg_cnt = 0; skb_queue_walk(target_list, pkt_next) { pkt_offset = 0; ... sg_cnt++; ... while (pkt_offset < pkt_next->len) { pkt_offset += sg_data_size; if (queued up max per request) mmc_submit_one(); } } if (sg_cnt) mmc_submit_one(); The variables that maintain where we are in the MMC command state such as req_sz, sg_cnt, and sgl are reset when we emit one of these full sized requests. Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 11:31:39 +0000