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>

If "evt_len" is 1 then we try to memcpy() negative 3 bytes and it would
cause memory corruption.

Fixes: d930faee ("mwifiex: add support for Marvell pcie8766 chipset")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Firmware already support hidden ssid and keep ssid length,
Open the capability in driver.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Firmware parse and attach ERP IE from bss configuration,
do not set again from tail IE.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Fix the following sparse warning in mwifiex_cmd_append_11n_tlv:

drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:358:65:    left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:358:65:    right side has type int
drivers/net/wireless/marvell/mwifiex/11n.c:360:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:360:65:    left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:360:65:    right side has type int
drivers/net/wireless/marvell/mwifiex/11n.c:366:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:366:65:    left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:366:65:    right side has type int
drivers/net/wireless/marvell/mwifiex/11n.c:368:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:368:65:    left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:368:65:    right side has type int

Fixes: 77423fa7 ("mwifiex: fix incorrect ht capability problem")
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

At present driver gets chan_type by referring to
IEEE80211_HT_PARAM_CHA_SEC_OFFSET, in ASSOC response. Sometimes
AP shows IEEE80211_HT_PARAM_CHA_SEC_OFFSET as above/below in
assoc response, even if the association is done on HT20 channel
only. So, it will be accurate to get econdary channel offset from
firmware.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

IEEE80211_CHAN_NO_HT40PLUS and IEEE80211_CHAN_NO_HT40PLUS channel
flags tell if HT40 operation is allowed on a channel or not.

This patch ensures ht_capability information is modified
accordingly so that we don't end up creating a HT40 connection
when it's not allowed for current regulatory domain.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This reverts commit bcc920e8.

Drivers gets hardware info and updates ht_cap field of
wiphy->bands during initialization. Once updated during init,
ht_cap must not be modified as it reflects the capability
supported by hardwawre. Above patch tries to modify the ht_cap
field and this results in wrongly advertising capabilities during
association.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

High bits of antenna number are reserved in hardware spec,
using low 4 bits represent supported antenna.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NXinming Hu <huxm@marvell.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>

Commit b014e96d ("PCI: Protect pci_error_handlers->reset_notify()
usage with device_lock()") resolves races between driver reset and
removal, but it introduces some new deadlock problems. If we see a
timeout while we've already started suspending, removing, or shutting
down the driver, we might see:

(a) a worker thread, running mwifiex_pcie_work() ->
    mwifiex_pcie_card_reset_work() -> pci_reset_function()
(b) a removal thread, running mwifiex_pcie_remove() ->
    mwifiex_free_adapter() -> mwifiex_unregister() ->
    mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work)

Unfortunately, mwifiex_pcie_remove() already holds the device lock that
pci_reset_function() is now requesting, and so we see a deadlock.

It's necessary to cancel and synchronize our outstanding work before
tearing down the driver, so we can't have this work wait indefinitely
for the lock.

It's reasonable to only "try" to reset here, since this will mostly
happen for cases where it's already difficult to reset the firmware
anyway (e.g., while we're suspending or powering off the system). And if
reset *really* needs to happen, we can always try again later.

Fixes: b014e96d ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()")
Cc: <stable@vger.kernel.org>
Cc: Xinming Hu <huxm@marvell.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This reverts commit b713bbf1.

The "fix" in question does not actually fix all related problems, and it
also introduces new deadlock possibilities. Since commit b014e96d
("PCI: Protect pci_error_handlers->reset_notify() usage with
device_lock()"), the race in question is actually resolved (PCIe reset
cannot happen at the same time as remove()). Instead, this "fix" just
introduces a deadlock where mwifiex_pcie_card_reset_work() is waiting on
device_lock, which is held by PCIe device remove(), which is waiting
on...mwifiex_pcie_card_reset_work().

The proper thing to do is just to fix the deadlock. Patch for this will
come separately.

Cc: Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The last command used to shutdown firmware might be timeout,
and trigger firmware dump in asynchronous pcie/sdio work.

The remove/shutdown handler will continue free core data
structure private/adapter, which might be dereferenced in
pcie/sdio work, finally crash the kernel.

Sync and Cancel pcie/sdio work, could be a fix for above
cornel case. In this way, the last command timeout could
be handled properly.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch extend device_dump debugfs function to make it
works for usb interface.

For command timeouts, USB firmware will automatically emit
firmware dump events, so we don't implement device_dump().

For user-initiated dumps, we trigger it by issue firmware
dump event command to firmware, as there is no command
response, do not start 10s timer.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Firmware dump on usb interface is different with current
sdio/pcie chipset, which is based on register operation.

When firmware hang on usb interface, context dump will be
upload to host using 0x73 firmware debug event.

This patch store dump data from debug event and send to
userspace using device coredump API.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@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>

(1) Change virtual interface operation in cfg80211 process reset and
reinitilize private data structure.
(2) Scan result event processed in main process will dereference private
data structure concurrently, ocassionly crash the kernel.

The cornel case could be trigger by below steps:
(1) wpa_cli mlan0 scan
(2) ./hostapd mlan0.conf

Cfg80211 asynchronous scan procedure is not all the time operated
under rtnl lock, here we add the protect to serialize the cfg80211
scan and change_virtual interface operation.
Signed-off-by: NLimin Zhu <liminzhu@marvell.com>
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Firmware do not support change interface from micro-ap mode
to station mode, forbid this operation
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Driver is transmitting in 11N rates, when connected to an AP in
TKIP security mode. Add a check to disable_11n to fix the issue.
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>

Use put_unaligned_le32 rather than using byte ordering function and
memcpy which makes code clear.
Also, add the header file where it is declared.

Done using Coccinelle and semantic patch used is :

@ rule1 @
identifier tmp; expression ptr,x; type T;
@@

- tmp = cpu_to_le32(x);

  <+... when != tmp
- memcpy(ptr, (T)&tmp, ...);
+ put_unaligned_le32(x,ptr);
  ...+>

@ depends on rule1 @
type j; identifier tmp;
@@

- j tmp;
  ...when != tmp
Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When a user requests scan, driver sends multiple scan requests
to firmware, which might be active or passive. Firmware will
send channel statistics for each channel in the request. This will
be stored in chan_stats array.

Few channels might report hidden SSIDs in passive scan results.
So, once the original scan request is finished, driver issues an
active scan request for all channels which reported hidden SSIDs.
This will cause duplicates in the chan_stats array. At worst,
every channel will have a hidden SSID, in which case the driver
can issue active scan requests for each channel. So the complete
scan statistics size will be twice of existing limit.

At present maximum number of channels returned in scan statistics
is 31(BG) + 14(A) = 45. Clearly there will be an overflow of the
chan_stats array in the above mentioned scenario. To fix this
double the size of chan_stats array.
Signed-off-by: NRohit Fule <rohitf@marvell.com>
Signed-off-by: NMangesh Malusare <mmangesh@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The sta_list_spinlock looks to be used to control locking of the
list. Specifically when someone has the lock they may be allowed
to modify or delete elements of the list.

That implies that we shouldn't access the fields of the elements
returned by mwifiex_get_sta_entry() after we've released the
spinlock. Let's make some small changes so this is true.

It's unlikely that this matters since it looks to be just error
handling, but it's nice to be clean.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

There's absolutely no reason to check to see if a list is empty
before iterating through it.  It's just like writing code like
this:

if (count != 0) {
  for (i = 0; i < count; i++) {
     ...
  }
}

The loop will already be avoided if "count == 0" so there was no
reason to check.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Driver will advertise RANDOM_MAC support only if the device
supports this feature.
Signed-off-by: NKarthik Ananthapadmanabha <karthida@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Don't populate the read-only const array tos_to_ac on the stack,
instead make it static. Makes the object code smaller by 250 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
  26104	   2720	    128	  28952	   7118	wmm.o

After:
   text	   data	    bss	    dec	    hex	filename
  25758	   2816	    128	  28702	   701e	wmm.o
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Avoid calculating random MAC address in driver. Instead make
use of 'get_random_mask_addr()' function.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Application will keep track of whether MAC address randomization
is enabled or not during scan. But at present driver is storing
'random_mac' in mwifiex_private which implies even after scan is
done driver has some reference to the earlier 'scan request'. To
avoid this, make use of 'mac_addr' variable in 'scan_request' to
store 'random_mac'. This structure will be freed by cfg80211 once
scan is done.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Don't populate const arrays on the stack, instead make them static
Makes the object code smaller by nearly 300 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
  69260	  16149	    576	  85985	  14fe1	cfg80211.o

After:
   text	   data	    bss	    dec	    hex	filename
  68385	  16725	    576	  85686	  14eb6	cfg80211.o
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

call to memset to assign 0 value immediately after allocating
memory with kzalloc is unnecesaary as kzalloc allocates the memory
filled with 0 value.

Semantic patch used to resolve this issue:

@@
expression e,e2; constant c;
statement S;
@@

  e = kzalloc(e2, c);
  if(e == NULL) S
- memset(e, 0, e2);
Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

If driver is loaded with 'mfg_mode' enabled, then the sending
commands are not allowed. So, skip sending commands, to firmware
in mwifiex_add_virtual_intf if 'mfg_mode' is enabled.

Fixes: 7311ea85 ("mwifiex: fix AP start problem for newly added interface")
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Driver sends a series of scan commands to firmware to serve a
user scan request. If an intermediate scan command fails, driver
aborts the scan but it is not being informed to cfg80211. This
will cause issues in applications performing periodic scans.
Fix this by informing scan abort.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

At the end of user scan request, driver will perform an active
scan for hidden SSIDs in passive channels. While doing this,
driver unconditionally adding random_mac in scan command, which
is no expected. It should add random_mac only if scan_request
has NL80211_SCAN_FLAG_RANDOM_ADDR flag set.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Driver should use random MAC address only if the scan is
requested by user(provided NL80211_SCAN_FLAG_RANDOM_ADDR
is set in scan request). It should not be used for a scan
performed before association.
Signed-off-by: NGanapathi Bhat <gbhat@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch check whether userspace beacon data include country
ie, if so then download command to enable 11d setup in firmeare
accordingly.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
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>

This patch wrapper wps ie in pass through tlv, so that
firmware could parse correctly.
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>