- 05 Apr, 2017 7 commits
-
-
Arend Van Spriel authored
To support network namespace the driver must assure all created network interfaces are in the same namespace as the wiphy instance and flag the support using WIPHY_FLAG_NETNS_OK. Verified using two terminals: Terminal 1 Terminal 2 -------------------------- --------------------------------- # ip netns add brcm-wifi # iw dev phy#0 Interface wlan3 ifindex 11 wdev 0x1 # ip netns exec brcm-wifi bash # iw dev # echo $$ 20337 # iw phy0 set netns 20337 # iw dev phy#0 Interface wlan3 ifindex 11 wdev 0x2 # iw phy0 interface add wl3.ap type __ap # iw dev phy#0 Interface wl3.ap ifindex 2 wdev 0x3 Interface wlan3 ifindex 11 wdev 0x2 # iw dev # iw phy0 set netns 1 # iw dev # iw dev phy#0 Interface wl3.ap ifindex 2 wdev 0x5 Interface wlan3 ifindex 11 wdev 0x4 Note: increasing wdev identifier above indicates issue in cfg80211 which is addressed separately. Tested-by:
Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Franky Lin authored
Move brcmf_fws_deinit into brcmf_proto_bcdc_detach since it is a bcdc exclusive feature. Signed-off-by:
-
Franky Lin authored
Create a new protocol layer interface brcmf_proto_init_cb for protocol layer to finish initialzation after core module components(fweh and etc.) are initialized. Signed-off-by:
-
Amitkumar Karwar authored
Chip goes into low power state when this feature is enabled. This was already enabled for SDIO and PCIe interface based chipsets. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Ganapathi Bhat authored
USB firmware added support for sending command response/event through interrupt endpoint, to enhance RX throughput. Added corresponding changes required to support this feature. This change takes care of backward compatibility with older firmware. Signed-off-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
-
Rafał Miłecki authored
For quite some time now brcmfmac supports 802.11ac chipsets and it's not limited to embedded devices only. There are even standalone PCIe cards based on BCM43602 or BCM4366. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.12. Major changes: ath10k * improve firmware download time for QCA6174 and QCA9377, especially helps resume time ath9k_htc * add support AirTies 1eda:2315 AR9271 device
-
- 22 Mar, 2017 2 commits
-
-
Roman Yeryomin authored
Basic support for MT7620 built-in wireless radio was added to OpenWrt in r41441. It has seen some heavy cleaning and refactoring since in order to match the Kernel's code quality standards. Signed-off-by:
Roman Yeryomin <roman@advem.lv> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Johan Hovold authored
Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: a1030e92 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device") Cc: Daniel Drake <dsd@gentoo.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
- 20 Mar, 2017 30 commits
-
-
Daniel Golle authored
Some of the macros used to describe the TX_PWR_CFG_4 register accidentally refer to TX_PWR_CFG_3, probably a copy&paste error. Fix that. Signed-off-by:
-
Colin Ian King authored
The check for rc < 0 is always false so the check is redundant and can be removed. Detected with CoverityScan, CID#101143 ("Logically dead code") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Franky Lin authored
Create a new protocol interface function brcmf_proto_reset_if for core module to notify protocol layer when interface role changes. Signed-off-by:
-
Franky Lin authored
Create a new protocol interface function brcmf_proto_del_if for core module to notify protocol layer upon interface deletion. Signed-off-by:
-
Franky Lin authored
fwsignal is only used by bcdc. Create a new protocol interface function brcmf_proto_add_if for core module to notify protocol layer upon a new interface is created. Signed-off-by:
-
Franky Lin authored
brcmf_txcomplete is invoked by sdio and usb bus module which are using bcdc protocol. So move it from core module into bcdc layer. Signed-off-by:
-
Franky Lin authored
brcmf_txflowblock is invoked by sdio and usb bus module which are using bcdc protocol. This patch makes it a bcdc API instead of a core module function. Reviewed-by:
-
Hans de Goede authored
If a scan gets aborted BRCMF_SCAN_STATUS_BUSY gets cleared in cfg->scan_status and when we receive an abort event from the firmware the BRCMF_SCAN_STATUS_BUSY check in the cfg80211_escan_handler will trigger resulting in multiple errors getting logged. Check for a status of BRCMF_E_STATUS_ABORT and in this case simply cleanly exit the cfg80211_escan_handler. This also avoids a BRCMF_E_STATUS_ABORT event arriving after a new scan has been started causing the new scan to complete prematurely without any data. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Hans de Goede authored
The country code gets set to "00" by default at boot, ignore this rather then logging an error about it. Signed-off-by:
-
Hans de Goede authored
Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we normally want to happen. Instead add a new brcmf_info macro and use that. Signed-off-by:
-
Rafał Miłecki authored
So far we were attaching BRCMF_E_PSM_WATCHDOG event listener in brcmf_debug_attach which gets compiled only with CONFIG_BRCMDBG. This event means something went wrong and firmware / hardware usually can't be expected to work (reliably). Such a problem is significant for user experience so I believe we should print an error unconditionally (even with debugging disabled). What can be indeed optional is dumping bus memory as this is clearly part of debugging process. In the future we may also try to extend this listener by trying to recover from the error or at least signal it to the cfg80211. Signed-off-by:
-
Rafał Miłecki authored
PCI devices can be described in DT as well so we should always execute relevant code. This will make bcma e.g. set of_node for cores described in DT. Signed-off-by:
-
Rafał Miłecki authored
A tiny code deduplication thanks to the bcma_bus_get_host_dev. Signed-off-by:
-
Rafał Miłecki authored
We already have the same check in bcma_of_get_irq which really calls symbols available with CONFIG_OF_IRQ only. It appears this duplicated check was accidentally added in commit c58d900c ("bcma: fix building without OF_IRQ"). The rest of code in bcma_of_fill_device should work fine without CONFIG_OF_IRQ. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ping-Ke Shih authored
Two additional preset responses are added to the reserved page on the wifi device. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
Changes in the drivers for RTL8723BE and RTL8821AE require corresponding changes in the firmware. This new firmware has been accepted into the Linux firmware repo. To handle the case where the kernel has been updated before the firmware, the new versions have been given new names. The code will attempt to read the new name, and fall back to the old one if the new one is not available. Signed-off-by:
-
Ping-Ke Shih authored
Update PHY tables for the RTL8812AE. A new parser is also needed. Signed-off-by:
-
Ping-Ke Shih authored
There are new PHY table values for the RTL8821AE. The changes require new parsing code. Signed-off-by:
-
Brian Norris authored
We observed a SHUTDOWN command timeout during reboot stress test due to a corner case firmware bug. It can lead to either a use-after-free + OOPS (on either the adapter structure, or the 'card' structure) or an abort (where, e.g., the PCI device is "disabled" before we're done dumping the FW). We can avoid this by canceling/flushing the FW dump work: (a) after we've terminated all other work queues (e.g., for processing commands which could time out) (b) after we've disabled all interrupts (which could also queue more work for us) (c) after we've unregistered the netdev and wiphy structures (and implicitly, and debugfs entries which could manually trigger FW dumps) (d) before we've actually disabled the device (e.g., pci_device_disable()) Altogether, this means no card->work will be scheduled if we sync at a point that satisfies the above. This can be done at the beginning of the .cleanup_if() callback. Signed-off-by:Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Amitkumar Karwar authored
Application triggers periodic background scans when device is connected. We will scan less number of channels per scan command so that data traffic won't get affected. Signed-off-by:
-
Devidas Puranik authored
Using the accessor function e.g. get_unaligned_le32 instead of le32_to_cpu to avoid the unaligned access. This is for the architectures that don't handle the unaligned memory access Signed-off-by:
Devidas Puranik <devidas@marvell.com> Signed-off-by:
-
Daniel Mentz authored
Synopsys' ARCompact architecture does not support loading from or storing values to unaligned memory locations. We saw a series of misaligned access exceptions on ARC. To work around this issue, we bulk replaced le16_to_cpu and le32_to_cpu with get_unaligned_le16 and get_unaligned_le32, respectively. We also added le16_unaligned_add_cpu which is similar to le16_add_cpu but works with unaligned values. Signed-off-by:
Daniel Mentz <danielmentz@google.com> Signed-off-by:
-
Karthik Ananthapadmanabha authored
Adding qualifier "__packed" indicates that no padding should be performed on the qualified object for alignment. This patch adds qualifier __packed to the required firmware structures in mwifiex driver. Signed-off-by:
Karthik Ananthapadmanabha <karthida@marvell.com> Signed-off-by:
-
Brian Norris authored
We shouldn't be printing a kernel pointer as a decimal integer. But we really shouldn't be printing this case at all; we should never get here with NULL drvdata. We've eliminated this unnecessary conditional in several other places, so kill it here too. Similarly, there's no need to check for '!pdev'; we are guaranteed to have a real device here. And finally, use dev_err() instead of pr_err(). This yields (for failed PCIe resets): [ 68.286586] mwifiex_pcie 0000:01:00.0: mwifiex_pcie_reset_notify: adapter structure is not valid instead of: [ 82.932658] mwifiex_pcie: mwifiex_pcie_reset_notify: Card or adapter structure is not valid (-270880688088) Signed-off-by:
-
Jeffy Chen authored
Currrently we are disabling this wake irq after receiving it. If this happens before we finish suspend and the pm event check is disabled, the system will continue suspending, and this irq would not work again. We may need to abort system suspend to avoid that. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
-
Alexandre Belloni authored
last_qual never really holds a time. It only holds jiffies. Make it the same type as jiffies. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Rostyslav Khudolii authored
Channels 34/38/42/46 can only be used for compatibility with old devices sold in Japan. Modern products, such as AR6003/AR6004 don't support these channels. Keeping them in the upstream is error prone and requires full network stack support. A custom patch should be used in case such compatibility is required. Without this one, a user is able to start an AP using wpa_supplicant, for example, on one of these channels (34/38/42/46), without getting any warning/error from the cfg80211 or ath6kl - which is correct (since these channels match regdom rules). However, the AR6003 and its firmware (we're using v3.4.0.225) will fail and return "WMI_CMDERROR_EVENTID" with "INVALID_PARAM" error code. Signed-off-by:
Rostyslav Khudolii <rkhudolii@airtame.com> Cc: Attila Sukosd <attila@airtame.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com>
-
Colin Ian King authored
The check of len > buf_len is redundant as len is initialized to 0 and buf_len to 4096, so this comparison is always false. Remove it. Signed-off-by:
-
Mohammed Shafi Shajakhan authored
Fix typo (spelling mistake) in wmi.h Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
I failed to notice that commit 523f6701 ("ath10k: update available channel list for 5G radio") added two new warnings: drivers/net/wireless/ath/ath10k/mac.c:3129:6: warning: symbol 'ath10k_mac_update_channel_list' was not declared. Should it be static? drivers/net/wireless/ath/ath10k/mac.c:3170: Alignment should match open parenthesis Fix those. Signed-off-by:
-
- 16 Mar, 2017 1 commit
-
-
Mohammed Shafi Shajakhan authored
Fetch target operating channel during potential radar detection when the interface is just brought up, but no channel is assigned from userspace. In this scenario rx_channel may not be having a valid pointer hence fetch the target operating channel to avoid warnings as below which can be triggered by the commands with DFS testing over longer run comamnds: iw wlan1 set type mesh ifconfig wlan1 up (valid tgt_oper_chan only) iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan) iw wlan1 cac trigger freq 5280 HT20 iw wlan1 cac trigger freq 5300 HT20 Once the CAC expires, current channel context will be removed and we are only left with the fallback option of using 'target operating channel' Firmware and driver log: ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6, count_false=11 ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6, count_false=4 ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar Call trace: WARNING: CPU: 1 PID: 2145 at backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265 cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]() Workqueue: phy1 ieee80211_dfs_radar_detected_work [mac80211] [<c0320770>] (warn_slowpath_null) from [<bf79b90c>] (cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]) [<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from [<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211]) [<bf79697c>] (cfg80211_radar_event [cfg80211]) from [<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211]) [<bf83c058>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4) Signed-off-by:
-
