commit 7afb94da3cd8a28ed7ae268143117bf1ac8a3371 upstream.

In set_mac_address, driver check for interfaces with same bss_type
For first STA entry, this would return 3 interfaces since all priv's have
bss_type as 0 due to kzalloc. Thus mac address gets changed for STA
unexpected. This patch adds check for first STA and avoids mac address
change. This patch also adds mac_address change for p2p based on bss_num
type.
Signed-off-by: NSharvari Harisangam <sharvari@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Cc: Brian Norris <briannorris@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Driver is using boolean variables to maintain vairous status
information of adapter. These status variables are accessed by
multiple threads and there is a possibility of a race. To avoid
this, convert these variables to a set of bitops flags, to be
operated atomically.

Below variables of mwifiex_adapter are converted to bitop flags:
surprise_removed
is_cmd_timedout
is_suspended
is_hs_configured
hs_enabling
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch makes it so that instead of passing a void pointer as the
accel_priv we instead pass a net_device pointer as sb_dev. Making this
change allows us to pass the subordinate device through to the fallback
function eventually so that we can keep the actual code in the
ndo_select_queue call as focused on possible on the exception cases.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

During changing virtual interface, keep using previous net device
mac address.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When interface type changed, firmware using a new connction pointer.
We need Re-configure the mac address.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

For user configurated mac address, directly set to firmware with no change.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Multiple interfaces with same bss type could affect each other if
they are sharing the same mac address. In this patch, different
mac address is assigned to new interface which have same bss type
with exist interfaces.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch refactor current device dump code to make it generic
for subsequent implementation on usb interface.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Trivial fix to spelling mistake in aggr_ctrl module parameter
message text.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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:
36908c4e mwifiex: uninit wakeup info when removing device
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NDavid S. Miller <davem@davemloft.net>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NHante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: NFranky Lin <franky.lin@broadcom.com>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

'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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: c742e623 ("mwifiex: sdio card reset enhancement")
Fixes: 4c5dae59 ("mwifiex: add PCIe function level reset support")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NDmitry Torokhov <dtor@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Reviewed-by: NDmitry Torokhov <dtor@chromium.org>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJohannes Berg <johannes.berg@intel.com>

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: 4c5dae59 ("mwifiex: add PCIe function level reset support")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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 853402a0 ("mwifiex: Enable
WoWLAN for both sdio and pcie").
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The mwifiex_dbg() log handler utilizes the struct device in
adapter->dev. Without it, it decides not to print anything.

As of commit 2e02b581 ("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: 2e02b581 ("mwifiex: Allow mwifiex early access to device structure")
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: 853402a0 ("mwifiex: Enable WoWLAN for both sdio and pcie")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NRajat Jain <rajatja@google.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Commit bec568ff 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: bec568ff ("mwifiex: failure path handling in mwifiex_add_virtual_intf()")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKirtika Ruchandani <kirtika@google.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NCathy Luo <cluo@marvell.com>
Signed-off-by: NShengzhen Li <szli@marvell.com>
Tested-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>