cfg_workqueue was added to notify cfg80211 that scan, connect
or disconnect is done by calling respective completion handlers.
We can avoid use of this workqueue by calling those handlers
from other places.
1) Call connect, disconnect completion handlers in their callback
   functions.
   ex. Call cfg80211_connect_result() in mwifiex_cfg80211_connect()
2) Call scan completion handler after parsing response of last scan
   command in a queue.

After removing the workqueue, variables (assoc_request etc.) and
checks used for mutual exclusion become redundant. Those are also
removed in this patch.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mwifiex driver no longer supports it's own custom regulatory rules,
but custom regulatory domain capability is still advertised during
wiphy registration by the driver.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mBm is passed but dBm was assumed...
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Following compilation warning is fixed by releasing referenced BSS
structure returned by cfg80211_inform_bss().

"warning: ignoring return value of cfg80211_inform_bss,
declared with attribute warn_unused_result"

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Making adding and deleting virtual interfaces dynamic. Adding
handlers for creating and deleting virtual interface with
given name and dev respectively.

Also, creating default interface of type station on insmod of
the driver.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"iw dev mlan0 link" shows wrong data rate, because data rate is
not sent properly to cfg80211 stack. Also stack is not updated
with mcs and Tx data flags information.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

An extra call to mwifiex_dump_station_info() routine in get_station
callback function is redundant
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_channel_to_frequency() routine expects band parameter in
the form of "enum ieee80211_band band". Currently driver specific
band (BAND_A, BAND_AN etc.) is passed to the routine.

This patch makes sure that correct parameter is passed.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In recent commit "mwifiex: use cfg80211 dynamic scan..."
(7c6fa2a8..) scan table handling in driver is removed to
make use of cfg80211 dynamic scan table. Now driver sends
beacon buffers found in scanning directly to stack and parse
the buffer for requested BSS only during association.

Beacon buffer doesn't contain bss band information. Driver
gets it from firmware in separate tlv (chan_band_tlv).
Currently since we don't inform stack about bss bandinfo,
there is an issue with 5GHz association.

Use "priv" field of struct cfg80211_bss to store bandinfo.
This fixes 5GHz association issue.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of maintaining static scan table in driver, scan list is sent
to cfg80211 stack (after parsing each scan command response).
In assoc handler (for infra and ibss network) requested BSS information
is retrieved using cfg80211_get_bss() API.

With the changes above some redundant code are removed.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

replace IW_MAX_AP & IW_CUSTOM_MAX with local definitions
and remove usage of struct iw_statistics.

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently, setting only legacy bitrates on 2.4GHz band
are supported. Mode 802.11b/g/bg is enabled based on
bitrates selection. If only CCK bitrates selected then
802.11b mode is enabled. If only OFDM bitrates are
selected then 802.11g mode is enabled. For both: CCK
and OFDM rates 802.11bg mixed mode is enabled.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Htcapinfo is unnecessarily sent in assoc request in WEP security due
to a regression introduced by commit 2be50b8d (mwifiex: remove
redundant encryption_mode mapping).
The issue is fixed in this patch.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Following OOPS was seen when booting with card inserted

 BUG: unable to handle kernel NULL pointer dereference at 0000004c
 IP: [<f8b7718c>] cfg80211_get_drvinfo+0x21/0x115 [cfg80211]
 *pde = 00000000
 Oops: 0000 [#1] SMP
 Modules linked in: iwl3945 iwl_legacy mwifiex_sdio mac80211 11 sdhci_pci sdhci pl2303

'ethtool' on the mwifiex device returned this OOPS as
wiphy_dev() returned NULL.

Adding missing set_wiphy_dev() call to fix the problem.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some structures and macros in ioctl.h are redundant or no longer
used.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch:
 - adds kfree() where necessary
 - prevents potential null dereferences
 - makes use of kfree_skb()
 - replaces -1 for failed kzallocs with -ENOMEM
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Reviewed-by: NKiran Divekar <dkiran@marvell.com>
Tested-by: NAmitkumar Karwar <akarwar@marvell.com>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Skip initialization of local variables with some default values
if the values are not going to be used further down the code path.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When scan and assoc (infra/ibss) commands are simultaneously
given in two terminals, association response is erroneously
served while serving the scan response.

mwifiex_cfg80211_results() is the common routine for sending
ioctl (scan, assoc etc.) results to cfg80211 stack. In above
scenario even if the common routine is called for scan ioctl
context, it also tries to send information about assoc ioctl to
cfg80211 because "priv->assoc_request/priv->ibss_join_request"
flag is on at that time.

Fix the issue by updating request variable after assoc handling
and modifying the variable check in mwifiex_cfg80211_results.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

1) Initialise HT capabilities in cfg80211 properly.
2) Cfg80211 stack may modify "sband->ht_cap" to disable
40Mhz operation in 2.4GHz band (after recent patch
"cfg80211: module_param to disable HT40 in 2.4GHz band")
Therefore read "sband->ht_cap" instead of an adapter variable
"hw_dot_11n_dev_cap" to get HT capabilities.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are some SD8787 cards which don't support 5GHz band.
Therefore initialise 5GHz band parameters only if hardware
supports the band.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove some local variables (mainly function return values)
that are used only once. Also, one dummy function and some
wordy comments are removed.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The return statement at the last line of a void function
is not necessary.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

1) remove mwifiex_alloc_fill_wait_queue() and
mwifiex_request_ioctl()
2) avoid dynamic allocation of wait queue
3) remove unnecessary mwifiex_error_code macros that
were used mainly by the wait queue status code
4) remove some abstraction functions
5) split mwifiex_prepare_cmd() to mwifiex_send_cmd_async()
and mwifiex_send_sync() to handle asynchronous and
synchronous commands respectively
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

remove MWIFIEX_ENCRYPTION_MODE_ and use WLAN_CIPHER_SUITE_
macros directly
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When testing wpa_supplicant with 'nl80211' driver to connect
to an AP with WPA/WPA2 security, we notice the followings:

1) add_key is called firstly with the key from cfg80211
2) set_defaut_key is called next

set_default_key() is specific to WEP keys and should not be
called in case of WPA/WPA2 security. The set_default_key()
won't be called if wpa_supplicant uses "-Dwext" option,
but it's been called if "-Dnl80211" option is specified.

We can fix this issue by adding a check to return from
set_default_key() if WEP key is not configured.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

replace them with NL80211_AUTHTYPE_ macros
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

replace them with NL80211_IFTYPE_ macros

Also remove redundant functions mwifiex_drv_get_mode()
and mwifiex_bss_ioctl_mode().
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The hw_dot_11n_dev_cap reported by firmware hw_spec
has different format than the 11n capabilities.
Hence a lot of SET_ and RESET_ bit operation macros
were used to convert the dev_cap format to 11n
capability format. However the locally defined 11n
ht_cap macros are not necessary as we can use
IEEE80211_HT_CAP_ macros directly.

The 32-bit dev_cap bitmap is added as comment to
explain the mapping between firmware and 11n spec.

Some unused macros and unnecessary adapter variables
are also removed.
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mwifiex_set_encrypt_mode()
mwifiex_set_auth_mode()
mwifiex_set_auth()
These functions are confusing and misleading.
And they are really not needed at all.

Some unused definitions are also removed.
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This driver adds WiFi support for Marvell 802.11n based chipsets
with SDIO interface. Currently only SD8787 is supported. More
chipsets will be supported later.

drivers/net/wireless/mwifiex/
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NRamesh Radhakrishnan <rramesh@marvell.com>
Signed-off-by: NFrank Huang <frankh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>