aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/marvell/mwifiex/main.c
Commit message (Collapse)AuthorAgeFilesLines
* mwifiex: refactor device dump code to make it generic for usb interfaceXinming Hu2018-01-081-46/+51
| | | | | | | | | | This patch refactor current device dump code to make it generic for subsequent implementation on usb interface. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: Convert timers to use timer_setup()Kees Cook2017-10-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Nishant Sarmukadam <nishants@marvell.com> Cc: Ganapathi Bhat <gbhat@marvell.com> Cc: Xinming Hu <huxm@marvell.com> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Johannes Berg <johannes.berg@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Andrew Zaborowski <andrew.zaborowski@intel.com> Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: p2p: use separate device addressXinming Hu2017-08-081-14/+26
| | | | | | | | | | | | | | | | | Per below statement about p2p device address in WFA P2P spec $2.4.3: The P2P Device Address of a P2P Device shall be its globally administered MAC address, or its globally administered MAC address with the locally administered bit set. This patch follow above statement, using a separate device address for p2p interface Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"Colin Ian King2017-07-281-1/+1
| | | | | | | | Trivial fix to spelling mistake in aggr_ctrl module parameter message text. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: uninit wakeup info in the error handlingJeffy Chen2017-07-281-1/+6
| | | | | | | | | | | | We inited wakeup info at the beginning of mwifiex_add_card, so we need to uninit it in the error handling. It's much the same as what we did in: 36908c4 mwifiex: uninit wakeup info when removing device Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: drop num CPU noticeBrian Norris2017-07-281-3/+1
| | | | | | | | | This print isn't very useful. It's also different between mwifiex_add_card() and mwifiex_reinit_sw(), and I'd like to consolidate them eventually. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: fixup init_channel_scan_gap error caseBrian Norris2017-07-281-1/+2
| | | | | | | | | In reading through _mwifiex_fw_dpc(), I noticed that after we've registered our wiphy, we still have error paths that don't free it back up. Let's do that. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: unregister wiphy before freeing resourcesBrian Norris2017-07-281-1/+6
| | | | | | | | | | | | | | | | | It's possible for some control interfaces (e.g., scans, set freq) to be active after we've stopped our main work queue and the netif TX queues. These don't get completely shut out until we've unregistered the wdevs and wiphy. So let's only free command buffers and poison our lists after wiphy_unregister(). This resolves various use-after-free issues seen when resetting the device. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: re-register wiphy across resetBrian Norris2017-07-281-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In general, it's helpful to use the same code for device removal as for device reset, as this tends to have fewer bugs. Let's move the wiphy unregistration code into the common reset and removal code. In particular, it's very hard to properly handle the reset sequence when something fails. Currently, if mwifiex_reinit_sw() fails, we've failed to unregister the associated wiphy, and so running something as simple as "iw phy" can trigger an OOPS, as the wiphy still has hooks back into freed mwifiex data structures. For example, KASAN complained: [... see reset fail for other reasons ...] [ 1184.821158] mwifiex_pcie 0000:01:00.0: info: dnld wifi firmware from 174948 bytes [ 1186.870914] mwifiex_pcie 0000:01:00.0: info: FW download over, size 608396 bytes [ 1187.685990] mwifiex_pcie 0000:01:00.0: WLAN FW is active [ 1187.692673] mwifiex_pcie 0000:01:00.0: cmd_wait_q terminated: -512 [ 1187.699075] mwifiex_pcie 0000:01:00.0: info: _mwifiex_fw_dpc: unregister device [ 1187.713476] mwifiex: Failed to bring up adapter: -5 [ 1187.718644] mwifiex_pcie 0000:01:00.0: reinit failed: -5 [... run `iw phy` ...] [ 1212.902419] ================================================================== [ 1212.909806] BUG: KASAN: use-after-free in mwifiex_cfg80211_get_antenna+0x54/0xfc [mwifiex] at addr ffffffc0ad1a8028 [ 1212.920246] Read of size 1 by task iw/3127 [...] [ 1212.934946] page dumped because: kasan: bad access detected [...] [ 1212.950665] Call trace: [ 1212.953148] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190 [ 1212.958572] [<ffffffc00020a96c>] show_stack+0x20/0x28 [ 1212.963648] [<ffffffc0005ce18c>] dump_stack+0xa4/0xcc [ 1212.968723] [<ffffffc0003c4430>] kasan_report+0x378/0x500 [ 1212.974140] [<ffffffc0003c3358>] __asan_load1+0x44/0x4c [ 1212.979462] [<ffffffbffc2e8360>] mwifiex_cfg80211_get_antenna+0x54/0xfc [mwifiex] [ 1212.987131] [<ffffffbffc084fc4>] nl80211_send_wiphy+0x75c/0x2de0 [cfg80211] [ 1212.994246] [<ffffffbffc094f60>] nl80211_dump_wiphy+0x32c/0x438 [cfg80211] [ 1213.001149] [<ffffffc000ab6404>] genl_lock_dumpit+0x48/0x64 [ 1213.006746] [<ffffffc000ab3474>] netlink_dump+0x178/0x398 [ 1213.012171] [<ffffffc000ab3d18>] __netlink_dump_start+0x1bc/0x260 [...] This all goes away if we just tear down the wiphy on the way down, and set it back up if/when we bring the device back up. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: reset interrupt status across device resetBrian Norris2017-07-281-0/+1
| | | | | | | | | | When resetting the device, we might have queued up interrupts that didn't get a chance to finish processing. We really don't need to handle them at this point; we just want to make sure they don't cause us to try to process old commands from before the device was reset. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: reunite copy-and-pasted remove/reset codeBrian Norris2017-07-281-76/+28
| | | | | | | | | | | | | | | | | | | | | | When PCIe FLR code was added, it explicitly copy-and-pasted much of mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary, as almost all of the code should be reused. Let's reunite what we can for now. The only functional changes for now: * call netif_device_detach() in the remove() code path -- this wasn't done before, but it really should be a no-op, when the device is getting totally unregistered soon anyway * call the ->down_dev() driver callback only after we've finished all SW teardown -- this should have no significant effect, since the only user (pcie.c) does very minimal work there, and it doesn't matter that we reorder this Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2017-06-151-1/+1
|\ | | | | | | | | | | | | The conflicts were two cases of overlapping changes in batman-adv and the qed driver. Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: Fix inconsistent teardown and release of private netdev state.David S. Miller2017-06-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Network devices can allocate reasources and private memory using netdev_ops->ndo_init(). However, the release of these resources can occur in one of two different places. Either netdev_ops->ndo_uninit() or netdev->destructor(). The decision of which operation frees the resources depends upon whether it is necessary for all netdev refs to be released before it is safe to perform the freeing. netdev_ops->ndo_uninit() presumably can occur right after the NETDEV_UNREGISTER notifier completes and the unicast and multicast address lists are flushed. netdev->destructor(), on the other hand, does not run until the netdev references all go away. Further complicating the situation is that netdev->destructor() almost universally does also a free_netdev(). This creates a problem for the logic in register_netdevice(). Because all callers of register_netdevice() manage the freeing of the netdev, and invoke free_netdev(dev) if register_netdevice() fails. If netdev_ops->ndo_init() succeeds, but something else fails inside of register_netdevice(), it does call ndo_ops->ndo_uninit(). But it is not able to invoke netdev->destructor(). This is because netdev->destructor() will do a free_netdev() and then the caller of register_netdevice() will do the same. However, this means that the resources that would normally be released by netdev->destructor() will not be. Over the years drivers have added local hacks to deal with this, by invoking their destructor parts by hand when register_netdevice() fails. Many drivers do not try to deal with this, and instead we have leaks. Let's close this hole by formalizing the distinction between what private things need to be freed up by netdev->destructor() and whether the driver needs unregister_netdevice() to perform the free_netdev(). netdev->priv_destructor() performs all actions to free up the private resources that used to be freed by netdev->destructor(), except for free_netdev(). netdev->needs_free_netdev is a boolean that indicates whether free_netdev() should be done at the end of unregister_netdevice(). Now, register_netdevice() can sanely release all resources after ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit() and netdev->priv_destructor(). And at the end of unregister_netdevice(), we invoke netdev->priv_destructor() and optionally call free_netdev(). Signed-off-by: David S. Miller <davem@davemloft.net>
* | mwifiex: usb: transmit aggregation packetsXinming Hu2017-05-311-0/+4
|/ | | | | | | | | | | | | | | | | | Instead of using 4KB packet buffer for data transfer, new chipset have more device memory. This patch try to aggregation packets in an 16KB buffer. In this way, totally usb transaction cost will be reduced. Thoughput test on usb 2.0 show both TCP TX and UPD TX promote ~40M, from ~240M to ~280M. This feature is default disabled, and can be enabled by module parameter, like: insmod mwifiex.ko aggr_ctrl=1 Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* cfg80211: add request id to cfg80211_sched_scan_*() apiArend Van Spriel2017-04-281-1/+1
| | | | | | | | | | | | Have proper request id filled in the SCHED_SCAN_RESULTS and SCHED_SCAN_STOPPED notifications toward user-space by having the driver provide it through the api. 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: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'wireless-drivers-next-for-davem-2017-04-21' of ↵David S. Miller2017-04-241-8/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.12 Quite a lot of patches for rtlwifi and iwlwifi this time, but changes also for other active wireless drivers. Major changes: ath9k * add support for Dell Wireless 1601 PCI device * add debugfs file to manually override noise floor ath10k * bump up FW API to 6 for a new QCA6174 firmware branch wil6210 * support 8 kB RX buffers iwlwifi * work to support A000 devices continues * add support for FW API 30 * add Geographical and Dynamic Specific Absorption Rate (SAR) support * support a few new PCI device IDs rtlwifi * work on adding Bluetooth coexistance support, not finished yet ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * mwifiex: don't leak 'chan_stats' on resetBrian Norris2017-04-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'chan_stats' is (re)allocated in _mwifiex_fw_dpc() -> mwifiex_init_channel_scan_gap(), which is called whenever the device is initialized -- at probe or at reset. But we only free it in we completely unregister the adapter, meaning we leak a copy of it during every reset. Let's free it in the shutdown / removal paths instead (and in the error-handling path), to avoid the leak. Ideally, we can eventually unify much of mwifiex_shutdown_sw() and mwifiex_remove_card() (way too much copy-and-paste) to reduce the burden on bugfixes like this. But that's work for tomorrow. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * mwifiex: reset timeout flag when resetting deviceBrian Norris2017-04-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we reset because of a command timeout, we should reset this flag. Otherwise, we might erroneously think the next command after reset is timing out, and trigger another reset. The above behavior effectively neuters the automatic card_reset() behavior, as it means we will never recover from a command timeout properly (and in fact, we might enter an infinite loop: timeout -> reset -> (fake) timeout -> reset -> ... This fixes a bug introduced with introduction of PCIe function level reset support, but it was carried into the SDIO driver when it was converted to use the same codepaths. And this is currently mostly a problem only in the SDIO driver, because it's the only one with automatic card_reset() support (e.g., on command timeout). But it will be a problem for PCIe too, as I'm working on supporting automatic card_reset() for PCIe. Fixes: c742e623e941 ("mwifiex: sdio card reset enhancement") Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not setXinming Hu2017-04-201-2/+5
| | | | | | | | | | | | | | | | | | | | mwifiex_dbg will do nothing before adapter->dev get assigned. several logs lost in this case. it can be avoided by fall back to pr_info. Signed-off-by: Xinming Hu <huxm@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * mwifiex: remove unnecessary wakeup interrupt number sanity checkXinming Hu2017-04-201-5/+3
| | | | | | | | | | | | | | | | | | | | | | If wakeup interrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* | Merge tag 'mac80211-next-for-davem-2017-04-18' of ↵David S. Miller2017-04-201-4/+3
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== My last pull request has been a while, we now have: * connection quality monitoring with multiple thresholds * support for FILS shared key authentication offload * pre-CAC regulatory compliance - only ETSI allows this * sanity check for some rate confusion that hit ChromeOS (but nobody else uses it, evidently) * some documentation updates * lots of cleanups ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * cfg80211: move add/change interface monitor flags into paramsJohannes Berg2017-04-131-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Instead passing both flags, which can be NULL, and vif_params, which are never NULL, move the flags into the vif_params and use BIT(0), which is invalid from userspace, to indicate that the flags were changed. While updating all drivers, fix a small bug in wil6210 where it was setting the flags to 0 instead of leaving them unchanged. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | Merge tag 'wireless-drivers-next-for-davem-2017-04-07' of ↵David S. Miller2017-04-091-12/+25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.12 Lots of bugfixes as usual but also some new features. Major changes: ath10k * improve firmware download time for QCA6174 and QCA9377, especially helps resume time ath9k_htc * add support AirTies 1eda:2315 AR9271 device rt2x00 * add support MT7620 mwifiex * enable auto deep sleep mode for USB chipsets brcmfmac * add support for network namespaces (WIPHY_FLAG_NETNS_OK) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | mwifiex: catch mwifiex_fw_dpc() errors properly in resetBrian Norris2017-04-051-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When resetting the device, we take a synchronous firmware-loading code path, which borrows a lot from the asynchronous path used at probe time. We don't catch errors correctly though, which means that in the PCIe driver, we may try to dereference the 'adapter' struct after mwifiex_fw_dpc() has freed it. See this (erronous) print in mwifiex_pcie_reset_notify(): mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__); Let's instead refactor the synchronous (or "!req_fw_nowait") path so that we propagate errors and handle them properly. This fixes a use-after-free issue in the PCIe driver, as well as a misleading debug message ("successful"). It looks like the SDIO driver doesn't have these problems, since it doesn't do anything after mwifiex_reinit_sw(). Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * | mwifiex: fix use-after-free for FW reinit errorsBrian Norris2017-04-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we fail to reinit the FW when resetting the device (in the synchronous version of mwifiex_init_hw_fw() -> mwifiex_fw_dpc()), mwifiex_fw_dpc() will tear down the interface and free up the adapter. But we don't actually check for all failure cases of mwifiex_fw_dpc(), so some of them fall through and dereference adapter->fw_done with a freed adapter, causing a use-after-free bug. In any case, mwifiex_fw_dpc() will always signal FW completion -- in the error OR success case -- so at best, this was repeat work. Let's not do it. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * | mwifiex: wake system up when receives a wake irqJeffy Chen2017-03-201-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | 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: Kalle Valo <kvalo@codeaurora.org>
* | mwifiex: uninit wakeup info when removing deviceBrian Norris2017-03-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We manually init wakeup info, but we don't detach it on device removal. This means that if we (for example) rmmod + modprobe the driver, the device framework might return -EEXIST the second time, and we'll complain in the logs: [ 839.311881] mwifiex_pcie 0000:01:00.0: fail to init wakeup for mwifiex AFAICT, there's no other negative effect. But we can fix this by disabling wakeup on remove, similar to what a few other drivers do (e.g., the power supply framework). This code (and bug) has existed on SDIO for a while, but it got moved around and enabled for PCIe with commit 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie"). Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* | mwifiex: set adapter->dev before starting to use mwifiex_dbg()Brian Norris2017-03-161-4/+4
|/ | | | | | | | | | | | | | | | | The mwifiex_dbg() log handler utilizes the struct device in adapter->dev. Without it, it decides not to print anything. As of commit 2e02b5814217 ("mwifiex: Allow mwifiex early access to device structure"), we started assigning that pointer only after we finished mwifiex_register() -- this effectively neuters any mwifiex_dbg() logging done before this point. Let's move the device assignment into mwifiex_register(). Fixes: 2e02b5814217 ("mwifiex: Allow mwifiex early access to device structure") Cc: Rajat Jain <rajatja@google.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: don't enable/disable IRQ 0 during suspend/resumeBrian Norris2017-02-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we don't have an out-of-band wakeup IRQ configured through DT (as most platforms don't), then we fall out of this function with 'irq_wakeup == 0'. Other code (e.g., mwifiex_disable_wake() and mwifiex_enable_wake()) treats 'irq_wakeup >= 0' as a valid IRQ, and so we end up calling {enable,disable}_irq() on IRQ 0. That seems bad, so let's not do that. Same problem as fixed in this patch: https://patchwork.kernel.org/patch/9531693/ [PATCH v2 2/3] btmrvl: set irq_bt to -1 when failed to parse it with the difference that: (a) this one is actually a regression and (b) this affects both device tree and non-device-tree systems While fixing the regression, also drop the verbosity on the parse failure, so we don't see this when a DT node is present but doesn't have an interrupt property (this is perfectly legal): [ 21.999000] mwifiex_pcie 0000:01:00.0: fail to parse irq_wakeup from device tree Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie") Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Rajat Jain <rajatja@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: cleanup in PCIe flr code pathXinming Hu2017-01-121-9/+0
| | | | | | | | | | | 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>
* mwifiex: get rid of mwifiex_do_flr wrapperXinming Hu2017-01-121-26/+5
| | | | | | | | | | | 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>
* mwifiex: get rid of drv_info* adapter variablesXinming Hu2017-01-121-25/+17
| | | | | | | | | 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>
* mwifiex: don't wait for main_process in shutdown_drvXinming Hu2017-01-121-37/+18
| | | | | | | | | | | | | | | | | | | | 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>
* mwifiex: Removed unused mwifiex_private* 'priv' variableKirtika Ruchandani2016-11-291-3/+0
| | | | | | | | | | | | | | 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>
* mwifiex: resolve races between async FW init (failure) and device removalBrian Norris2016-11-191-30/+17
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mwifiex: complete blocked power save handshake in main processShengzhen Li2016-11-191-4/+5
| | | | | | | | | | | | | | | 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>
* mwifiex: Enable WoWLAN for both sdio and pcieRajat Jain2016-11-191-0/+41
| | | | | | | | | | 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>
* mwifiex: Introduce mwifiex_probe_of() to parse common propertiesRajat Jain2016-11-191-0/+12
| | | | | | | | | | | | | | Introduce function mwifiex_probe_of() to parse common properties. Interface drivers get to decide whether or not the device tree node was a valid one (depending on the compatible property), Lets fill "adapter->dt_node" in mwifiex_add_card(). The function mwifiex_probe_of() is currently only a place holder with the next patch adding content to it. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: Allow mwifiex early access to device structureRajat Jain2016-11-191-1/+3
| | | | | | | | | | | | | | | | | | | Today all the interface drivers (usb/pcie/sdio) assign the adapter->dev in the register_dev() callback, although they have this piece of info well before hand. This patch makes the device structure available for mwifiex right at the beginning, so that it can be used for early initialization if needed. This is needed for subsequent patches in this patchset that intend to unify and consolidate some of the code that would otherwise have to be duplicated among the interface drivers (sdio, pcie, usb). Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: fix null pointer deference when adapter is nullColin Ian King2016-09-171-4/+4
| | | | | | | | | | | | | If adapter is null the error exit path in mwifiex_shutdown_sw is to down the semaphore sem and print some debug via mwifiex_dbg. However, passing a NULL adapter to mwifiex_dbg causes a null pointer deference when accessing adapter->dev. This fix checks for a null adapter at the start of the function and to exit without the need to up the semaphore and we also skip the debug to avoid the null pointer dereference. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: add PCIe function level reset supportAmitkumar Karwar2016-09-091-15/+227
| | | | | | | | | | | | | | | | This patch implements pre and post FLR handlers to support PCIe FLR functionality. Software cleanup is performed in pre-FLR whereas firmware is downloaded and software is re-initialised in post-FLR handler. Following command triggers FLR. echo "1" > /sys/bus/pci/devices/$NUMBER/reset This feature can be used as a recovery mechanism when firmware gets hang. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: add manufacturing mode supportXinming Hu2016-09-091-4/+22
| | | | | | | | | | | | | | By default normal mode is chosen when driver is loaded. This patch adds a provision to choose manufacturing mode via module parameters. Below command loads driver in manufacturing mode insmod mwifiex.ko mfg_mode=1. Tested-by: chunfan chen <jeffc@marvell.com> Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: add custom regulatory domain supportAmitkumar Karwar2016-09-031-0/+2
| | | | | | | | This patch creates custom regulatory rules based on the information received from firmware and enable them during wiphy registration. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* nl80211: support beacon report scanningAvraham Stern2016-07-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Beacon report radio measurement requires reporting observed BSSs on the channels specified in the beacon request. If the measurement mode is set to passive or active, it requires actually performing a scan (passive or active, accordingly), and reporting the time that the scan was started and the time each beacon/probe was received (both in terms of TSF of the BSS of the requesting AP). If the request mode is table, this information is optional. In addition, the radio measurement request specifies the channel dwell time for the measurement. In order to use scan for beacon report when the mode is active or passive, add a parameter to scan request that specifies the channel dwell time, and add scan start time and beacon received time to scan results information. Supporting beacon report is required for Multi Band Operation (MBO). Signed-off-by: Assaf Krauss <assaf.krauss@intel.com> Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mwifiex: fix link error against sdioArnd Bergmann2016-06-181-6/+0
| | | | | | | | | | | | | | | | | | | | Calling sdio_claim_host() from the interface independent part of the mwifiex driver is not only a layering violation, but also causes a link error if MMC support is disabled, or if CONFIG_MMC=m and CONFIG_MWIFIEX=y: drivers/net/built-in.o: In function `mwifiex_fw_dpc': :(.text+0xff138): undefined reference to `sdio_claim_host' :(.text+0xff158): undefined reference to `sdio_release_host' The right way to do this is to have the sdio specific code in the sdio driver front-end, and we already have a callback pointer that we can use for this after exporting the generic fw download function from the core driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 65c71efe1c59 ("mwifiex: fix racing condition when downloading firmware") Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: fix racing condition when downloading firmwareWei-Ning Huang2016-06-141-2/+10
| | | | | | | | | | | | | | | | | | The action 'check for winner' and 'download firmware' should be an atomic action. This is true for btmrvl driver but not mwmfiex, which cause firmware download to fail when the following senerio happens: 1) mwifiex check winner status: true 2) btmrvl check winner status: true, and start downloading firmware 3) mwfieix tries to download firmware, but failed because btmrvl is already downloading. This won't happen if 1) and 3) is an atomic action. This patch adds sdio_claim/release_host call around those two actions to make sure it's atomic. Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: stop background scan when net device closedXinming Hu2016-04-261-7/+7
| | | | | | | | | Transmit data path should not touch background scan. We will stop background scan when net device is closed. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: do not wait on semaphore during card removalXinming Hu2016-04-141-1/+1
| | | | | | | | | | | | | | | | | Host hang is observed if card is removed before firmware download gets completed. In this case, firmware will be failed to download and adapter structure gets freed. In other thread, mwifiex_remove_card() waits on semaphore until the firmware download fails. This wait is not necessary and may result in invalid adapter access. This patch uses down_trylock to return immediately so that hang issue won't occur. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: dump pcie scratch registersXinming Hu2016-04-071-3/+5
| | | | | | | | | This patch prints pcie scratch registers during firmware dump. They will be useful for analysing firmware status. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: add wowlan net-detect supportchunfan chen2016-01-291-0/+7
| | | | | | | | | | This patch adds support for wakeup when configured network is detected. Signed-off-by: chunfan chen <jeffc@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2025-03-01 08:22:08 +0000