This is a flaw in recently implemented logic to handle Tx traffic
and scan operation simultaneously. We missed to wakeup main thread
to handle Tx traffic if scan is delayed/aborted.

For some cards (SD8797, for example), firmware will send SLEEP event
if there is no activity for 50msec. While handling the SLEEP event,
main thread will be woken up and Tx packet gets sent hence. In worst
case Tx traffic will be delayed for 50msec.

For other cards, such as USB8797, firmware won't send SLEEP event.
So, Tx traffic gets stuck if no other event triggers the wakeup of
main thread.

This patch fixes above issues.
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>

Add support for parsing WPA IE from beacon parameter of
cfg80211_ap_settings and set it to FW.

WPA/WPA2 mixed mode is supported with this patch.
Signed-off-by: NAvinash Patil <patila@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>

Conflicts:
	drivers/net/wireless/ti/wl18xx/main.c

After 934b9d1e (wl18xx: avoid some -Wformat warnings) there was still
a warning with (at least) ARM gcc version 4.4.1:

drivers/net/wireless/ti/wl18xx/main.c: In function 'wl18xx_conf_init':
drivers/net/wireless/ti/wl18xx/main.c:1026: warning: format '%ld' expects type 'long int', but argument 2 has type 'unsigned int'

Fix this by using %zu for the both formats, since the fw->size and the
macro (derived from sizeof()) are size_t.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Remove the cap IEEE80211_HT_CAP_DSSSCCK40 from the 5Ghz variant of
the siso40 HT capabilities. It is meaningless in 5Ghz.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Introduce a default set of HT capabilities that are set according to the
number of antennas on the board. Move the HT setting code down to allow
the number of antennas to be set (and optionally overridden) before it.

Remove the "mimo" HT option, since the default mode now enables MIMO is
possible.

Use this opportunity to add a helper function for setting HT
capabilities and reduce the volume of the code a bit.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The 18xx chip does not support MIMO in 5Ghz. Use the siso20 HT cap as
fallback in 5Ghz when "mimo" is requested.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

FW uses a few memory blocks as a buffer to accumulate FW logs before
transmitting them to the host over SDIO. When FW WatchDog recovery
occurs, the last FW traces are still pending in the buffer. Driver is
to read these FW traces whether log mode is continuous or on demand.

FW memory blocks allocated for the log buffer are handled as a link list:
the first 4 bytes in each memory block contain FW address to the next block.
The end of list condition depends on FW log mode:
- on demand: the list is cyclic, the next address is equal to the first address
- continuous: the address is  equal to 0x2000000

Log data resides inside FW memory block with offset depending on
logger mode:
- on demand:  4 bytes (address of the next memory block)
- continuous: 4 bytes and Rx Descriptor structure size

Described FW logger API is backward compatible with previous FW versions.
Signed-off-by: NIgal Chernobelsky <igalc@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The get survey op expects the low level driver to report
the noise level for a a given channel.

The noise calculated in wlcore is (rssi-snr/2), but since
the snr reported by the FW is a derivative from the rssi
this calculation is useless, and should not be reported
to the user space.

Reporting incorrect noise, results in the wpa_supplicant
miscalculating the roaming candidate priority, thus causing
a situation where an AP with a lower rssi level would be
chosen over a better AP.
Signed-off-by: NYoni Divinsky <yoni.divinsky@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Before patch b5d6d9b2 (wlcore/wl12xx/wl18xx: don't use TX align quirk
for wl127x), this was automatically set for all platforms. As this
should now be set explicitly, set it for PG2 as well.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

New PG2 firmwares have additional Rx descriptors.

Add a module parameter to manually set the number of Rx descriptors for
older versions (PG1). We cannot discriminate based on chip-id, since
this value must be set on probe.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The sleep_auth value of the last interface to be set up prevailed when
an interface was removed. Take care of this by correctly configuring the
value according to the remaining STA/AP interfaces.

Take this opportunity to refactor the sleep_auth setting code for better
readability.

[Small style fix. -- Luca]
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Hold a value for sta_sleep_auth that is amenable to change by debugfs.
When detecting a legal value in this variable on interface init, use it
as an override value for sleep_auth.

This makes debugging more intuitive using the debugfs value.

Increment the conf version since we added an element to the conf
structure.

Note: An AP going up will always set sleep_auth to PSM_CAM.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

For FW debugging purposes, we may need to change the sleep mode
(aka. sleep_auth) by hand, and set it to the mode we want.  To allow
this, a debugfs entry is added.

Now we store the sleep_auth value that has been set and use that
instead of the quirk to decide whether we should enter ELP or not.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>

The ampdu_action() function is called on the reconfig() path to remove
existing Rx BA sessions. Since these don't exist for the low level
driver, we output an error message. Turn the message into a debug
message for now, until the mac80211 reconfig flow is changed.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Currently when mac80211 asks to change the interface
type, we will accept it for both the BSS and PAN
contexts. This is not terribly complicated today,
but with the addition of the P2P Device abstraction
the PAN context handling will get more complex, so
restrict mac_change_interface to the BSS context.

Also fix a small locking issue and use is_active
instead of the vif pointer to check if the other
context is activated, guarding exclusive interface
types on the BSS context (IBSS) against the PAN
context being used for something else.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the first interface is active, then scanning
on it or the second interface can take a little
longer than 7s (I observed around 8s.) Bump the
timeout to 15s to avoid aborting a scan that is
still running, just taking more time.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My previous commit to shorten the radio reset time
caused issues as the firmware checks the active
dwell time against the quiet time, asserting that
the dwell is >= quiet time. This isn't really
needed in case of passive scanning like here, but
of course we need to pass that check.

To fix this, override the quiet time to be the
same as the radio reset dwell time.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

With gcc 4.7.x, the following warning is issued as the routine that sets
the array has the possibility of not initializing the values:

  CC [M]  drivers/net/wireless/rtlwifi/rtl8192se/phy.o
drivers/net/wireless/rtlwifi/rtl8192se/phy.c: In function ‘rtl92s_phy_set_txpower’:
drivers/net/wireless/rtlwifi/rtl8192se/phy.c:1268:23: warning: ‘ofdmpowerLevel[0]’ may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The baseband and cycle counters are being sampled during ani
processing for debugging purpose. Whenever the ani is postponded
due to sleep state, taking samples on that time is of no use and
also unneccesarily waking up the chip might increase the power
consumption on idle associated state. Hence moving debug function
within powersave block.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When WLAN enter full sleep mode, WLAN HW should send out a LNA_TAKE
message for BT to take control of the shared LNA. Otherwise BT traffic
is completely stopped whenever the wlan interface is moved full sleep
mode.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During driver stop, btcoex is disabled and also btcoex_hw.enabled
is set to false. Afterwards mci_is_enabled returns false so that
BT is not gaining SPDT control on WLAN sleep. Fix that.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

WLAN driver initialization is muting BT which is terminating
the ongoing BT traffic. The reason to mute BT is to avoid any
incoming MCI messages from BT when MCI reset is in progress that
could corrupt WLAN MCI RX state machine. But we should not
dedicate radio completely to WLAN in driver init itself. So this
patch removes the wlan weightage changes from mute BT to retain
BT connection.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Two MCI interrupts are generated while adding A2DP and headset profiles
with different types and same connection handle. While disconnecting,
only one MCI interrupt is generated with last added profile type value
for both profiles.

While adding second profile type decrement first one.
Signed-off-by: NBala Shanmugam <bkamatch@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Firmware supports changing filters using ACX_RX_CFG command,
so use it in .configure_filter callback. Firmware also supports
probe request filtering, so add it too along the way.
This will also re-enable BSSID filter which is now removed by
join command while associating.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This driver has a hack in cmd.c which effectively disables all filtering.
This seems to be triggering a firmware bug where it stops reporting any
rx packets after random time on some routers, which is eliminated (or at
least appears much more rarely) when filtering is on.
I have found that only BSSID filter needs to be disabled for association
to work, so disable only that instead of all filtering.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

filter_work is never used, remove it.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The brcmsmac internal regulatory data is being used to determine whether
OFDM should be allowed, and this is only done once during
initialization. To be effective this needs to be checked against
mac80211's regulatory rules for the current channel.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The core regulatory support will disable channels not allowed by
regulatory rules, so brcmsmac doesn't need to check whether or not the
requested channel is permitted by regulatory.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the limits from the internal X2 domain are used, regardless
of what regulatory rules are in effect. Instead use the power limits set
by the higher-level regulatory support.

The rules for the MIMO power limits are still always derived from the
world domain, pending guidance from Broadcom as to how these need to be
handled. This will be fixed later, but using the limits from the world
domain works for now.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the radio disable state is only updated during initialization,
and it's only checked against the internal world domain. This is
unnecessary, as there are always valid channels against this domain.
Instead, check whether any channels are enabled in the regulatory
notifier and update the radio state accordingly.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

brcmsmac implements enforcement of regulatory constraints internally,
using a Broadcom-specific world roaming domain named X2. Besides being
duplication of functionality this can also conflict with mac80211's
regulatory implementation, as mac80211 is unaware of the X2 domain and
thus might apply a more restrictive domain.

This patch is the first step in making brcmsmac cooperate with
mac80211's regulatory support. X2 is registered as a custom domain with
mac80211, so that at least both implementations will be enforcing the
same set of constraints. The internal enforcement of rules is kept for
now; this will be converted over to relying on mac80211 regulatory
enforcement in later patches.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Much of the code is either unsed or never put to any useful purpose.
Remove this code in advance of reworking the driver's regulatory
support.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NBrett Rudley <brudley@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This code has been kept around in anticipation of adding support for
40MHz channels, but subsequent patches to better integrate with mac80211
regulatory support will render it completely broken. Therefore we should
go ahead and remove it.

Keep these changes separate from other cleanup patches in order to make
it easier to resurrect 40MHz channel support at some point in the
future.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In some situations brcmsmac is choosing a channel internally. This makes
it difficult at times to know what channel to use for enforcing
regulatory constraints, so instead always use the channel from the
mac80211 configuration.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This code is unnecessary, and in fact it's never executed because the
interface is never up when brcms_c_channels_commit() is called. Removing
it helps simplify the implementation of proper regulatory support.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NBrett Rudley <brudley@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>