summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/marvell/mwifiex
AgeCommit message (Collapse)Author
2017-01-20mwifiex: don't complain about 'unknown event id: 0x63'Brian Norris
Marvell folks tell me this is a debugging event that the driver doesn't need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of these sorts of messages at (for instance) boot time: [ 13.825848] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 14.838561] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 14.850397] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 32.529923] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 Let's handle this "event" with a much lower verbosity. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-20mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE()Brian Norris
In mwifiex_delay_for_sleep_cookie(), we're looping and waiting for the PCIe endpoint to write a magic value back to memory, to signal that it has finished going to sleep. We're not letting the compiler know that this might change underneath our feet though. Let's do that, for good hygiene. I'm not aware of this fixing any concrete problems. I also give no guarantee that this loop is actually correct in any other way, but at least this looks like an improvement to me. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-20mwifiex: pcie: don't loop/retry interrupt status checksBrian Norris
The following sequence occurs when using IEEE power-save on 8997: (a) driver sees SLEEP event (b) driver issues SLEEP CONFIRM (c) driver recevies CMD interrupt; within the interrupt processing loop, we do (d) and (e): (d) wait for FW sleep cookie (and often time out; it takes a while), FW is putting card into low power mode (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value But at (e), no one actually signaled an interrupt (i.e., we didn't check adapter->int_status). And what's more, because the card is going to sleep, this register read appears to take a very long time in some cases -- 3 milliseconds in my case! Now, I propose that (e) is completely unnecessary. If there were any additional interrupts signaled after the start of this loop, then the interrupt handler would have set adapter->int_status to non-zero and queued more work for the main loop -- and we'd catch it on the next iteration of the main loop. So this patch drops all the looping/re-reading of PCIE_HOST_INT_STATUS, which avoids the problematic (and slow) register read in step (e). Incidentally, this is a very similar issue to the one fixed in commit ec815dd2a5f1 ("mwifiex: prevent register accesses after host is sleeping"), except that the register read is just very slow instead of fatal in this case. Tested on 8997 in both MSI and (though not technically supported at the moment) MSI-X mode. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-20mwifiex: pcie: use posted write to wake up firmwareBrian Norris
Depending on system factors (e.g., the PCIe link PM state), the first read to wake up the Wifi firmware can take a long time. There is no reason to use a (blocking, non-posted) read at this point, so let's just use a write instead. Write vs. read doesn't matter functionality-wise -- it's just a dummy operation. But let's make sure to re-write with the correct "ready" signature, since we check for that in other parts of the driver. This has been shown to decrease the time spent blocking in this function on RK3399. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-19mwifiex: remove redundant dma padding in AMSDUXinming Hu
We already ensure 64 bytes alignment and add padding if required during skb_aggr allocation. Alignment and padding in mwifiex_11n_form_amsdu_txpd() is redundant. We may end up accessing more data than allocated size with this. This patch fixes following issue by removing redundant padding. [ 370.241338] skbuff: skb_over_panic: text:ffffffffc046946a len:3550 put:72 head:ffff880000110000 data:ffff8800001100e4 tail:0xec2 end:0xec0 dev:<NULL> [ 370.241374] ------------[ cut here ]------------ [ 370.241382] kernel BUG at net/core/skbuff.c:104! 370.244032] Call Trace: [ 370.244041] [<ffffffff8c3df5ec>] skb_put+0x44/0x45 [ 370.244055] [<ffffffffc046946a>] mwifiex_11n_aggregate_pkt+0x1e9/0xa50 [mwifiex] [ 370.244067] [<ffffffffc0467c16>] mwifiex_wmm_process_tx+0x44a/0x6b7 [mwifiex] [ 370.244074] [<ffffffffc0411eb8>] ? 0xffffffffc0411eb8 [ 370.244084] [<ffffffffc046116b>] mwifiex_main_process+0x476/0x5a5 [mwifiex] [ 370.244098] [<ffffffffc0461298>] mwifiex_main_process+0x5a3/0x5a5 [mwifiex] [ 370.244113] [<ffffffff8be7e9ff>] process_one_work+0x1a4/0x309 [ 370.244123] [<ffffffff8be7f4ca>] worker_thread+0x20c/0x2ee [ 370.244130] [<ffffffff8be7f2be>] ? rescuer_thread+0x383/0x383 [ 370.244136] [<ffffffff8be7f2be>] ? rescuer_thread+0x383/0x383 [ 370.244143] [<ffffffff8be83742>] kthread+0x11c/0x124 [ 370.244150] [<ffffffff8be83626>] ? kthread_parkme+0x24/0x24 [ 370.244157] [<ffffffff8c4da1ef>] ret_from_fork+0x3f/0x70 [ 370.244168] [<ffffffff8be83626>] ? kthread_parkme+0x24/0x24 Fixes: 84b313b35f8158d ("mwifiex: make tx packet 64 byte DMA aligned") Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-17mwifiex: debugfs: Fix (sometimes) off-by-1 SSID printBrian Norris
Similar to commit fcd2042e8d36 ("mwifiex: printk() overflow with 32-byte SSIDs"), we failed to account for the existence of 32-char SSIDs in our debugfs code. Unlike in that case though, we zeroed out the containing struct first, and I'm pretty sure we're guaranteed to have some padding after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes long). So, this is the difference between: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef " ... and the correct output: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef" ... Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-17mwifiex: fix uninitialized variable access in pcie_removeArnd Bergmann
Checking the firmware status from PCIe register only works if the register is available, otherwise we end up with random behavior: drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove': drivers/net/wireless/marvell/mwifiex/pcie.c:585:5: error: 'fw_status' may be used uninitialized in this function [-Werror=maybe-uninitialized] This makes sure we treat the absence of the register as a failure. Fixes: 045f0c1b5e26 ("mwifiex: get rid of global user_rmmod flag") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: get rid of global save_adapter and sdio_workXinming Hu
This patch moves sdio_work to card structure, in this way we can get adapter structure in the work, so save_adapter won't be needed. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: get rid of __mwifiex_sdio_remove helperXinming Hu
__mwifiex_sdio_remove helper is not needed after our enhancements in SDIO card reset. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: sdio card reset enhancementXinming Hu
Commit b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset") introduces a simple sdio card reset solution based on card remove and re-probe. This solution has proved to be vulnerable, as card and adapter structures are not protected, concurrent access will result in kernel panic issues. Let's reuse PCIe FLR's functions for SDIO reset to avoid freeing and reallocating adapter and card structures. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: cleanup in PCIe flr code pathXinming Hu
adapter and card variables don't get freed during PCIe function level reset. "adapter->ext_scan" variable need not be re-initialized. fw_name and tx_buf_size initialization is moved to pcie specific code so that mwifiex_reinit_sw() can be used by SDIO. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: get rid of mwifiex_do_flr wrapperXinming Hu
This patch gets rid of mwifiex_do_flr. We will call mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly. These two general purpose functions will be useful for sdio card reset handler. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: use module_*_driver helper macrosAmitkumar Karwar
After user_rmmod global flag removal, *_init_module() and *_cleanup_module() have become just a wrapper functions. We will get rid of them with the help of module_*_driver() macros. For pcie, existing ".init_if" handler has same name as what module_pcie_driver() macro will create. Let's rename it to avoid conflict. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: get rid of global user_rmmod flagXinming Hu
bus.remove() callback function is called when user removes this module from kernel space or ejects the card from the slot. The driver handles these 2 cases differently. Few commands (FUNC_SHUTDOWN etc.) are sent to the firmware only for module unload case. The variable 'user_rmmod' is used to distinguish between these two scenarios. This patch checks hardware status and get rid of global variable user_rmmod. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: code rearrangement in pcie.c and sdio.cXinming Hu
Next patch in this series is going to use mwifiex_read_reg() in remove handlers. The changes here are prerequisites to avoid forward declarations. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: move pcie_work and related variables inside cardGanapathi Bhat
Currently pcie_work and related variables are global. It may create problem while supporting multiple devices simultaneously. Let's move it inside card structure so that separate instance will be created/ cancelled in init/teardown threads of each connected devices. Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: wait firmware dump complete during card remove processXinming Hu
Wait for firmware dump complete in card remove function. For sdio interface, there are two diffenrent cases, card reset trigger sdio_work and firmware dump trigger sdio_work. Do code rearrangement for distinguish between these two cases. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: get rid of drv_info* adapter variablesXinming Hu
We can avoid drv_info_dump and drv_info_size adapter variables. This info can be passed to mwifiex_upload_device_dump() as parameters Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: do not free firmware dump memory in shutdown_drvXinming Hu
mwifiex_upload_device_dump() already takes care of freeing firmware dump memory. Doing the same thing in mwifiex_shutdown_drv() is redundant. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-12mwifiex: don't wait for main_process in shutdown_drvXinming Hu
main_process is not expected to be running when shutdown_drv function is called. currently we wait for main_process completion in the function. Actually the caller has already made sure main_process is completed by performing below actions. (1) disable interrupts in if_ops->disable_int. (2) set adapter->surprise_removed = true, main_process wont be queued. (3) mwifiex_terminate_workqueue(adapter), wait for workqueue to be completed. This patch removes redundant wait code and takes care of related cleanup. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-30mwifiex: Enable dynamic bandwidth signallingAmitkumar Karwar
Enable dynamic bandwidth signalling by setting the corresponding bit in MAC control register. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-30mwifiex: change width of MAC control variableAmitkumar Karwar
Firmware has started making use of reserved field. Accordingly change curr_pkt_filter from u16 to u32. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-30mwifiex: sdio: fix use after free issue for save_adapterAmitkumar Karwar
If we have sdio work requests received when sdio card reset is happening, we may end up accessing older save_adapter pointer later which is already freed during card reset. This patch solves the problem by cancelling those pending requests. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-05mwifiex: clean up some messy indentingDan Carpenter
These lines were indented one tab extra. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Couple conflicts resolved here: 1) In the MACB driver, a bug fix to properly initialize the RX tail pointer properly overlapped with some changes to support variable sized rings. 2) In XGBE we had a "CONFIG_PM" --> "CONFIG_PM_SLEEP" fix overlapping with a reorganization of the driver to support ACPI, OF, as well as PCI variants of the chip. 3) In 'net' we had several probe error path bug fixes to the stmmac driver, meanwhile a lot of this code was cleaned up and reorganized in 'net-next'. 4) The cls_flower classifier obtained a helper function in 'net-next' called __fl_delete() and this overlapped with Daniel Borkamann's bug fix to use RCU for object destruction in 'net'. It also overlapped with Jiri's change to guard the rhashtable_remove_fast() call with a check against tc_skip_sw(). 5) In mlx4, a revert bug fix in 'net' overlapped with some unrelated changes in 'net-next'. 6) In geneve, a stale header pointer after pskb_expand_head() bug fix in 'net' overlapped with a large reorganization of the same code in 'net-next'. Since the 'net-next' code no longer had the bug in question, there was nothing to do other than to simply take the 'net-next' hunks. Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-02Merge tag 'wireless-drivers-next-for-davem-2016-12-01' 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.10 Major changes: rsi * filter rx frames * configure tx power * make it possible to select antenna * support 802.11d brcmfmac * cleanup of scheduled scan code * support for bcm43341 chipset with different chip id * support rev6 of PCIe device interface ath10k * add spectral scan support for QCA6174 and QCA9377 families * show used tx bitrate with 10.4 firmware wil6210 * add power save mode support * add abort scan functionality * add support settings retry limit for short frames bcma * add Dell Inspiron 3148 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29mwifiex: pcie: implement timeout loop for FW programming doorbellBrian Norris
Marvell Wifi PCIe modules don't always behave nicely for PCIe power management when their firmware hasn't been loaded, particularly after suspending the PCIe link one or more times. When this happens, we might end up spinning forever in this status-polling tight loop. Let's make this less tight by adding a timeout and by sleeping a bit in between reads, as we do with the other similar loops. This prevents us from hogging a CPU even in such pathological cases, and allows the FW initialization to just fail gracefully instead. I chose the same polling parameters as the earlier loop in this function, and empirically, I found that this loop never makes it more than about 12 cycles in a sane FW init sequence. I had no official information on the actual intended latency for this portion of the download. Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Remove unused 'bcd_usb' variableKirtika Ruchandani
mwifiex_usb_probe() defines and sets bcd_usb but does not use it, Compiling with W=1 gives the following warning, fix it. mwifiex/usb.c: In function ‘mwifiex_usb_probe’: mwifiex/usb.c:383:41: warning: variable ‘bcd_usb’ set but not used [-Wunused-but-set-variable] The unused variable seems to be present since 4daffe354366 which introduced mwifiex_usb_probe(). Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset") Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Removed unused 'pkt_type' variableKirtika Ruchandani
Commit 92263a841b15 introduced mwifiex_deaggr_sdio_pkt which initializes variable pkt_type but does not use it. Compiling with W=1 gives the following warning, fix it. mwifiex/sdio.c: In function ‘mwifiex_deaggr_sdio_pkt’: mwifiex/sdio.c:1198:6: warning: variable ‘pkt_type’ set but not used [-Wunused-but-set-variable] Fixes: 92263a841b15 ("mwifiex: add SDIO rx single port aggregation") Cc: Zhaoyang Liu <liuzy@marvell.com> Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Remove unused 'pm_flag' variableKirtika Ruchandani
mwifiex_sdio_resume() intializes pm_flag, just like mwifiex_sdio_suspend(), but does not use it. Compiling with W=1 gives the following warning, fix it. mwifiex/sdio.c: In function ‘mwifiex_sdio_resume’: mwifiex/sdio.c:234:16: warning: variable ‘pm_flag’ set but not used [-Wunused-but-set-variable] sdio_get_host_pm_caps() is just an acessor, so the call to it is safe to remove. The unused variable seems to be present since 5e6e3a92b9a4 which introduced mwifiex_sdio_resume(). Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: Bing Zhao <bzhao@marvell.com> Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Remove unused 'adapter'variableKirtika Ruchandani
Commit 3935ccc14d2c introduced mwifiex_tm_cmd() which initializes struct mwifiex_adapter* adapter, but doesn't use it. Compiling with W=1 gives the following warning, fix it. mwifiex/cfg80211.c: In function ‘mwifiex_tm_cmd’: mwifiex/cfg80211.c:3973:26: warning: variable ‘adapter’ set but not used [-Wunused-but-set-variable] Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support") Cc: Xinming Hu <huxm@marvell.com> Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Remove unused 'sta_ptr' variableKirtika Ruchandani
Commit 429d90d2212b introduced mwifiex_cmd_tdls_oper() which initializes struct mwifiex_sta_node* sta_ptr, but does not use it. Compiling with W=1 gives the following warning, fix it. mwifiex/sta_cmd.c: In function ‘mwifiex_cmd_tdls_oper’: mwifiex/sta_cmd.c:1732:27: warning: variable ‘sta_ptr’ set but not used [-Wunused-but-set-variable] Fixes: 429d90d2212b ("mwifiex: add cfg80211 tdls_oper handler support") Cc: Avinash Patil <patila@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Remove unused 'chan_num' variableKirtika Ruchandani
Commit b5413e6b2228 removed all uses of chan_num in mwifiex_config_scan(). Compiling mwifiex with W=1 gives the following warning, fix it. mwifiex/scan.c: In function ‘mwifiex_config_scan’: mwifiex/scan.c:830:6: warning: variable ‘chan_num’ set but not used [-Wunused-but-set-variable] Fixes: b5413e6b2228 ("mwifiex: increase the number of nodes in command pool") Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-29mwifiex: Removed unused mwifiex_private* 'priv' variableKirtika Ruchandani
Commit bec568ff5107 removed the last remaining usage of struct mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to mwifiex_del_virtual_intf(). Compiling mwifiex/ with W=1 gives the following warning, fix it. mwifiex/main.c: In function ‘mwifiex_fw_dpc’: mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] Fixes: bec568ff5107 ("mwifiex: failure path handling in mwifiex_add_virtual_intf()") Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-27Merge tag 'wireless-drivers-next-for-davem-2016-11-25' 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.10 Major changes: iwlwifi * finalize and enable dynamic queue allocation * use dev_coredumpmsg() to prevent locking the driver * small fix to pass the AID to the FW * use FW PS decisions with multi-queue ath9k * add device tree bindings * switch to use mac80211 intermediate software queues to reduce latency and fix bufferbloat wl18xx * allow scanning in AP mode ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-25mwifiex: Disable adhoc feature based on firmware capabilityKarthik D A
We will read fw_cap_info filled by firmware to check whether to skip ADHOC related commands or not. Also, IBSS_COALESCING_STATUS command has been moved from init path to adhoc network creation path. Signed-off-by: Karthik D A <karthida@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-25mwifiex: avoid double-disable_irq() raceBrian Norris
We have a race where the wakeup IRQ might be in flight while we're calling mwifiex_disable_wake() from resume(). This can leave us disabling the IRQ twice. Let's disable the IRQ and enable it in case if we have double-disabled it. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-25mwifiex: cleanup wake-IRQ handling if suspend failsBrian Norris
We don't want to leave the wake IRQ enabled. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: pcie: stop checking for NULL adapter->cardBrian Norris
It should never be NULL here, and to think otherwise makes things confusing. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: stop checking for NULL drvata/intfdataBrian Norris
These are never NULL, so stop making people think they might be. I don't change this for SDIO because SDIO has a racy card-reset handler that reallocates this struct. I'd rather not touch that mess right now. Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: sdio: don't check for NULL sdio_funcBrian Norris
sdio_func is retrieved via container_of() and should never be NULL. Checking for NULL just makes the logic more confusing than necessary. Stop doing that. Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: usb: handle HS failuresBrian Norris
SDIO and PCIe drivers handle this. Let's imitate it. Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: reset card->adapter during device unregisterXinming Hu
card->adapter gets initialized in mwifiex_register_dev(). As it's not cleared in mwifiex_unregister_dev(), we may end up accessing the memory which is already free in below scenario. Scenario: Driver initialization is failed due to incorrect firmware or some other reason. Meanwhile device reboot/unload occurs. This is safe, now that we've properly synchronized suspend() and remove() with the FW initialization thread; now that code can simply check for 'card->adapter == NULL' and exit safely. Signed-off-by: Xinming Hu <huxm@marvell.com> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: resolve suspend() race with async FW init failureBrian Norris
Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: don't pretend to resume while remove()'ingBrian Norris
The device core will not allow suspend() to race with remove(). Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: remove redundant pdev check in suspend/resume handlersAmitkumar Karwar
to_pci_dev() would just do struct offset arithmetic on struct device to get 'pdev' pointer. We never get NULL pdev pointer. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: resolve races between async FW init (failure) and device removalBrian Norris
It's possible for the FW init sequence to fail, which will trigger a device cleanup sequence in mwifiex_fw_dpc(). This sequence can race with device suspend() or remove() (e.g., reboot or unbind), and can trigger use-after-free issues. Currently, this driver attempts (poorly) to synchronize remove() using a semaphore, but it doesn't protect some of the critical sections properly. Particularly, we grab a pointer to the adapter struct (card->adapter) without checking if it's being freed or not. We later do a NULL check on the adapter, but that doesn't work if the adapter was freed. Also note that the PCIe interface driver doesn't ever set card->adapter to NULL, so even if we get the synchronization right, we still might try to redo the cleanup in ->remove(), even if the FW init failure sequence already did it. This patch replaces the static semaphore with a per-device completion struct, and uses that completion to synchronize the remove() thread with the mwifiex_fw_dpc(). A future patch will utilize this completion to synchronize the suspend() thread as well. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: complete blocked power save handshake in main processShengzhen Li
Power save handshake with firmware might be blocked by on-going data transfer. this patch check the PS status in main process and complete previous blocked PS handshake. this patch also remove redudant check before call mwifiex_check_ps_cond function. Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Shengzhen Li <szli@marvell.com> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: check tx_hw_pending before downloading sleep confirmShengzhen Li
We may get SLEEP event from firmware even if TXDone interrupt for last Tx packet is still pending. In this case, we may end up accessing PCIe memory for handling TXDone after power save handshake is completed. This causes kernel crash with external abort. This patch will only allow downloading sleep confirm when no tx done interrupt is pending in the hardware. Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Shengzhen Li <szli@marvell.com> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-19mwifiex: Enable WoWLAN for both sdio and pcieRajat Jain
Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt support") added WoWLAN feature only for sdio. This patch moves that code to the common module so that all the interface drivers can use it for free. It enables pcie and sdio for its use currently. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-27 14:21:40 +0000