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

When user adds a virtual interface driver will set the
bss_type to the iface_type given by the user. When
supplicant is started on the same interface, a call to
change_virtual_intf will be triggered if if_type is not
NL80211_IFTYPE_STATION. Here driver should not update
it's bss_type, because bss_type is intended to indicate
the original iface_type and changing the same will defeat
the purpose of creating this interface.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.

An spatch similar to the one for skb_put_zero() converts many
of the places using it:

    @@
    identifier p, p2;
    expression len, skb, data;
    type t, t2;
    @@
    (
    -p = skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    |
    -p = (t)skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, len);
    |
    -memcpy(p, data, len);
    )

    @@
    type t, t2;
    identifier p, p2;
    expression skb, data;
    @@
    t *p;
    ...
    (
    -p = skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    |
    -p = (t *)skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, sizeof(*p));
    |
    -memcpy(p, data, sizeof(*p));
    )

    @@
    expression skb, len, data;
    @@
    -memcpy(skb_put(skb, len), data, len);
    +skb_put_data(skb, data, len);

(again, manually post-processed to retain some comments)
Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The semaphore 'async_sem' is used as a simple mutex, so
it should be written as one. Semaphores are going away in the future.
Signed-off-by: NBinoy Jayan <binoy.jayan@linaro.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

If we fail to add an interface in mwifiex_add_virtual_intf(), we might
hit a BUG_ON() in the networking code, because we didn't tear things
down properly. Among the problems:

 (a) when failing to allocate workqueues, we fail to unregister the
     netdev before calling free_netdev()
 (b) even if we do try to unregister the netdev, we're still holding the
     rtnl lock, so the device never properly unregistered; we'll be at
     state NETREG_UNREGISTERING, and then hit free_netdev()'s:
	BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
 (c) we're allocating some dependent resources (e.g., DFS workqueues)
     after we've registered the interface; this may or may not cause
     problems, but it's good practice to allocate these before registering
 (d) we're not even trying to unwind anything when mwifiex_send_cmd() or
     mwifiex_sta_init_cmd() fail

To fix these issues, let's:

 * add a stacked set of error handling labels, to keep error handling
   consistent and properly ordered (resolving (a) and (d))
 * move the workqueue allocations before the registration (to resolve
   (c); also resolves (b) by avoiding error cases where we have to
   unregister)

[Incidentally, it's pretty easy to interrupt the alloc_workqueue() in,
e.g., the following:

  iw phy phy0 interface add mlan0 type station

by sending it SIGTERM.]

This bugfix covers commits like commit 7d652034 ("mwifiex: channel
switch support for mwifiex"), but parts of this bug exist all the way
back to the introduction of dynamic interface handling in commit
93a1df48 ("mwifiex: add cfg80211 handlers add/del_virtual_intf").

Cc: <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
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>

For multiple scheduled scan support the driver needs to know which
scheduled scan request is being stopped. Pass the request id in the
.sched_scan_stop() callback.
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>

This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.

Drivers currently supporting scheduled scan are now indicating they support
a single scheduled scan request. This obsoletes WIPHY_FLAG_SUPPORTS_SCHED_SCAN.
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>
[clean up netlink destroy path to avoid allocations, code cleanups]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan
request that should be randomized; the absence of such a flag means we
should not randomize. However, mwifiex was stashing the latest
randomization request and *always* using it for future scans, even those
that didn't set the flag.

Let's zero out the randomization info whenever we get a scan request
without NL80211_SCAN_FLAG_RANDOM_ADDR. I'd prefer to remove
priv->random_mac entirely (and plumb the randomization MAC properly
through the call sequence), but the spaghetti is a little difficult to
unravel here for me.

Fixes: c2a8f0ff ("mwifiex: support random MAC address for scanning")
Cc: <stable@vger.kernel.org> # 4.9+
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Pass the new extended ACK reporting struct to all of the generic
netlink parsing functions. For now, pass NULL in almost all callers
(except for some in the core.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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 IEEE80211_CHAN_RADAR is set by cfg80211, passive scan must be
performed. In mwifiex,active scan is performed even though flag is
set from cfg80211. mwifiex_reg_apply_radar_flags() function added
in this patch correctly uses radar flag.
Signed-off-by: NKarthik Ananthapadmanabha <karthida@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The comment on the name indirection suggested an issue but turned out
to be untrue. Digging in older kernel version showed issue with ipw2x00
but that is no longer true so get rid on the name indirection.
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit 3935ccc1 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: 3935ccc1 ("mwifiex: add cfg80211 testmode support")
Cc: Xinming Hu <huxm@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKirtika Ruchandani <kirtika@google.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NKarthik D A <karthida@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
when we print them out.

This can be easily noticed by connecting to a network with a 32-octet
SSID:

[ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
'0123456789abcdef0123456789abcdef <uninitialized mem>' bssid
xx:xx:xx:xx:xx:xx

Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Cc: <stable@vger.kernel.org>
Acked-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Add the missing destroy_workqueue() before return from
mwifiex_add_virtual_intf() in the error handling case.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Marvell p2p device disappears from the list of p2p peers on the other
p2p device after disconnection.

It happens due to a bug in driver. When interface is changed from p2p
to station, certain variables(bss_type, bss_role etc.) aren't correctly
updated. This patch corrects them to fix the issue.
Signed-off-by: NKarthik D A <karthida@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

At couple of places in cleanup path, we are just going through the
skb queue and freeing them without unlinking. This leads to a crash
when other thread tries to do skb_dequeue() and use already freed node.

The problem is freed by unlinking skb before freeing it.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Previously device used to start using IGTK key as Tx key as soon as it
gets downloaded in add_key(). This patch implements set_default_mgmt_key
handler. We will update Tx key ID in set_default_mgmt_key().
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Currently Rx STBC in assoc request frame is advertised as 3. It should
be 2, as our chipsets support two spatial streams.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch adds cfg80211 testmode support so that userspace tools can
download necessary commands to firmware during manufacturing mode tests.
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 creates custom regulatory rules based on the information
received from firmware and enable them during wiphy registration.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Disconnect message in mwifiex_reset_connect_state() would displays
necessary information. We unnecessarily have exactly same message in
cfg80211_disconnect(). As priv->cfg_bssid is cleared at this point of
time, it prints incorrect(all zero) MAC.

This message is removed here.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch advertises RANDOM_MAC_ADDR feature to cfg80211. It allow the
application to issue scan with a MAC address and mask. Random MACs are
generated and used in probe requests sent for scanning until it is changed
by the application or device is restarted.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

memory is malloced in mwifiex_cfg80211_start_ap() and should be
freed before leaving from the error handling cases, otherwise it
will cause memory leak.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

scan_block flag is used to block scan operation when 4 way handshake
is in progress. Sometimes it doesn't get cleared due to incomplete
association. An example is assoc request/response is done, but add key
operation get canceled in some corner cases. As a result, further
association/scan operations are blocked.

This patch fixes the problem by clearing scan_block flag.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch fixes below NULL pointer dereference observed in suspend
stress test. When scan is cancelled during system suspend, we may end
up aceesing "priv->scan_request" in corner case.

[ 3035.304682] BUG: KASAN: null-ptr-deref on address 0000000000000008
[ 3035.304704] Read of size 4 by task ksdioirqd/mmc2/1183
[ 3035.304744] CPU: 0 PID: 1183 Comm: ksdioirqd/mmc2 Tainted: G        W      3.18.0 #1169
[ 3035.304772] Call trace:
[ 3035.304825] [<ffffffc00020a520>] dump_backtrace+0x0/0x190
[ 3035.304864] [<ffffffc00020a6cc>] show_stack+0x1c/0x28
[ 3035.304901] [<ffffffc000b36db8>] dump_stack+0xa0/0xf8
[ 3035.304940] [<ffffffc00039c494>] kasan_report+0x120/0x4fc
[ 3035.304975] [<ffffffc00039b6b4>] __asan_load4+0x20/0x80
[ 3035.305546] [<ffffffbffc1f5aec>] mwifiex_check_next_scan_command+0x1a4/0x588 [mwifiex]
[ 3035.306091] [<ffffffbffc1f7aec>] mwifiex_handle_event_ext_scan_report+0x304/0x370 [mwifiex]
[ 3035.306735] [<ffffffbffc206bb8>] mwifiex_process_sta_event+0x6c0/0xf10 [mwifiex]
[ 3035.307200] [<ffffffbffc1e609c>] mwifiex_process_event+0x2f4/0x358 [mwifiex]
[ 3035.307612] [<ffffffbffc1e25c8>] mwifiex_main_process+0x3cc/0x80c [mwifiex]
[ 3035.307737] [<ffffffbffc2523a0>] mwifiex_sdio_interrupt+0x198/0x1c0 [mwifiex_sdio]
[ 3035.307785] [<ffffffc0008d9250>] process_sdio_pending_irqs+0x15c/0x1d4
[ 3035.307826] [<ffffffc0008d93f0>] sdio_irq_thread+0xd8/0x288
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We will derive sta_priv at the beginning of suspend handler.
This will be useful for next patch in this series.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Since commit de3bb771 ("cfg80211: add more warnings for inconsistent
ops") the wireless core warns if a driver implements a cfg80211 callback
but doesn't implements the inverse operation.

The mwifiex driver defines a .set_antenna handler but not a .get_antenna
so this not only makes the core to print a warning when creating a new
wiphy but also the antenna isn't reported to user-space apps such as iw.

This patch queries the antenna to the firmware so is properly reported to
user-space. With this patch, the wireless core does not warn anymore and:

$ iw phy phy0 info | grep Antennas
        Available Antennas: TX 0x3 RX 0x3
        Configured Antennas: TX 0x3 RX 0x3
Signed-off-by: NShengzhen Li <szli@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
[javier: expand the commit message]
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The mwifiex driver implements a cfg80211 .set_tx_power operation handler
but doesn't have the inverse .get_tx_power callback.

This not only has the effect that the Tx power can't be reported to user
space tools such as iwconfig and iwlist but also that the wireless core
prints a warning when a new wiphy is created due an cfg80211 operation
being implemented without its counterpart.

After this patch, the Tx power is properly reported to user-space tools:

$ iwlist mlan0 txpower
mlan0     unknown transmit-power information.

          Current Tx-Power=13 dBm       (19 mW)

and also the following warning isn't shown anymore on the driver probe:

WARNING: CPU: 3 PID: 127 at net/wireless/core.c:366 wiphy_new_nm+0x66c/0x6ac
Modules linked in: mwifiex_sdio mwifiex
CPU: 3 PID: 127 Comm: kworker/3:1 Tainted: G        W       4.7.0-rc1-next-20160531-00006-g569df5b983f3
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events request_firmware_work_func
[<c010e1ac>] (unwind_backtrace) from [<c010af38>] (show_stack+0x10/0x14)
[<c010af38>] (show_stack) from [<c0323b9c>] (dump_stack+0x88/0x9c)
[<c0323b9c>] (dump_stack) from [<c011a828>] (__warn+0xe8/0x100)
[<c011a828>] (__warn) from [<c011a8f0>] (warn_slowpath_null+0x20/0x28)
[<c011a8f0>] (warn_slowpath_null) from [<c06a42d4>] (wiphy_new_nm+0x66c/0x6ac)
[<c06a42d4>] (wiphy_new_nm) from [<bf1c24cc>] (mwifiex_register_cfg80211+0x28/0x3f0 [mwifiex])
[<bf1c24cc>] (mwifiex_register_cfg80211 [mwifiex]) from [<bf1a0018>] (mwifiex_fw_dpc+0x2b0/0x474 [mwifiex])
[<bf1a0018>] (mwifiex_fw_dpc [mwifiex]) from [<c040eb74>] (request_firmware_work_func+0x30/0x58)
[<c040eb74>] (request_firmware_work_func) from [<c012fe90>] (process_one_work+0x124/0x338)
[<c012fe90>] (process_one_work) from [<c01300dc>] (worker_thread+0x38/0x4d4)
[<c01300dc>] (worker_thread) from [<c01353b8>] (kthread+0xdc/0xf4)
[<c01353b8>] (kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c)
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The commit 7311ea85 ("mwifiex: fix AP start problem for newly added
interface") attempted to fix an issue when a new AP interface is added.

But the patch didn't check the return value of the functions doing the
firmware calls and returned an error even if the functions didn't fail.

This prevents the network device to be registered properly, so fix it.

Fixes: 7311ea85 ("mwifiex: fix AP start problem for newly added interface")
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It's been observed that if interface type is changed from managed to
__ap, AP can be successfully started. But there is a problem if new
ap interface is added.

The problem got resolved after sending appropriate commands to firmware
in add_interface handler.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It is obeserved that sometimes scan operation will block the disconnect
during system suspend. It's ok to cancel ongoing scan in this case. It
reduces unnecessary system suspend delay.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In cfg80211 resume handler, we query wakeup reason from firmware and
report to cfg80211. if wowlan is disabled, connection is already
terminated during suspend. We don't need to query wakeup reason in this
case.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It's been observed that wakeup on GTK rekey failure wasn't reported
to cfg80211. This patch corrects the check so that all valid wakeup
reasons are reported.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Redundant space in case statement is removed.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

User can configure wakeup on GTK rekey fail with wowlan.
Added corresponding wakeup reason.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Added driver functionality to offload GTK rekey to firmware. When
AP sends new GTK, firmware will update it.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>