wlan: Release 3.2.1.13

The following changes were incorporated in this release:
===
Dump neighbor state info when scan is not allowed

This commit only adds a debug statement and supplements the changes
made previously.
===
Improve convergence of LFR roam candidate scan algorithm

When no roam candidates are found, the existing scan algorithm takes
long time to converge and there is no guarantee that all channels
will be scanned. This not only impacts power consumption, but also
affects roam convergence by not being able to find roam candidates
quickly. The algorithm is being modified as follows in an attempt
to address both power and convergence of the algorithm:
1. If no candidates were found for the very first time, re-register
with TL by lowering the lookup threshold by 3 dBm. Once look up DOWN
notification is received, we will scan on channels in the occupied
list followed by ALL valid channels not in the occupied list.
2. If still no candidates are found, start neighbor scan results
refresh timer (default is 20s). Upon expiry of the timer, once again
scan on channels in the occupied list followed by ALL valid channels
not in the occupied list.
3. If still no candidates are found, abort scanning and go back to
connected state. At this instant, only lookup UP event is registered
with TL.

This changelist includes the following:
a) Above mentioned scan algorithm.
b) Populate occupied list only with channels where candidates
matching the profile are found.
c) Initialize the occupied list only when a connection is made to
a profile different from the previous profile.
d) Use lookup UP threshold 2dB higher than lookup DOWN threshold.

NOTE: This change is being made ONLY for LFR.
===
De-register lookup UP indication during pre-auth

Upon receiving a lookup UP indication, it suggests that the link to the
current AP has improved and we clean-up all scan control info before
moving back to connected state. However, if we receive a lookup UP
indication while we are in the middle of a pre-auth, it can lead to
several race conditions:

1) Lookup UP indication received after SME posted pre-auth message
to PE and before PE posts the auth response back to SME.
In this instance, while SME layer cancels the pre-auth, the PE/LIM
would have created an FT session which goes unaccounted for. This extra
session causes subsequent scans to fail and eventually results in a
HB failure.

2) Lookup UP indication received after reassoc and before key exchange.
This instance is even more severe. When this happens, we would ignore
the connect indication received following key exchange. Due to this,
all layers except the neighbor roam engine has moved to the new AP
while the roam engine still thinks we are associated to the older AP.
Due to this mis-matched roam profile, we end up: (i) rejecting new
candidate APs found during scan, (ii) pre-auth with the AP we are
currently associated to, etc.

This is being fixed by de-registering for lookup UP indication
as soon as we receive the reassoc DOWN indication. If the pre-auth
fails with all available roam candidates, we once again register
for a lookup UP indication.
===
Only flush non-P2P results from scan cache prior to LFR scan

Currently, we flush the scan results from the scan cache prior to
LFR scans. This might unnecessarily purge P2P scan results and
might delay finding P2P clients in concurrency mode. This fix only
purges non-P2P clients prior to LFR scans.
===
Insure that LFR BG scanning is not performed for any non-Infra association

Insure that LFR BG scanning is not performed for any non-Infra
association. Modify csrRoamIsFastRoamEnabled() to check the persona
for the association. Return FALSE is the persona is not VOS_STA_MODE.
===
Remove call to palStopTimer for preauth

Remove call to palStopTimer in csrNeighborRoamPreauthRspHandler.
===
Fix driver hang in csrRoamRoamingStateDisassocRspProcessor

During roam, we disassociate with the current AP before reassociating
with the new one. Upon receiving the disassoc response from PE, we
look-up for the hand-off candidate in the scan results list to get
the Bss description. If this look-up fails, the current code is
unable to recover and leads to a driver hang. While it removes the
roam command from SME active queue, it does not reschedule another
one from the pending queue due to which no pending SME commands
get processed and the SME queue gets stuck.

The recovery mechanism is being fixed as follows:
1. Look-up for the hand-off candidate in the scan results list.
2. If the look-up fails, then we need to disconnect and clean-up.
a) For this, inform HDD about the roam failure and disconnect.
b) Post a disassoc request to PE with BSSID of hand-off candidate
so that it cleans-up the FT session that was created when pre-auth
was completed.
c) Upon receiving the disassoc response, call csrRoamComplete with
reason as eCsrJoinFailure so that SME layer cleans-up as well. This
also takes care of removing the roam command from the active queue
and schedules the next command from the pending queue, thereby
unblocking the SME layer.
===
Populate Correct Scan Mode for Roam

The init scan request in Riva is failing with reason code
"QWLANFW_STATUS_BMPS_NO_REPLY_TO_NULLFRAME_FROM_AP".  In Riva in case
of roaming, we should be ignoring the tx complete status and hence not
returning a failure when transmission of NULL frame to the AP
fails. However since the scan mode populated in the init scan request
sent from the host is incorrect we are seeing a failure. This fix is
to populate the scan mode in LIM to reflect a roaming type regardless
of the next state.
===
Send EDCA Parameters After Reassoc

The EDCA parameters are being sent down to Riva before receiving the
reassoc response, as a result all the values in the request are
zero. Send the EDCA parameters after re-assoc response is received.
===
Update csrRoamInitGlobals() to support static linking

For Nexus 4 the WLAN driver is statically linked.  On this platform it
was observed that occasionally if a P2P session was established, that
subsequently the HotSpot mode could not be enabled (reference Google
bug 7499425: Cannot enable WiFi-Tethering, if WiFi-Direct was
connected).  Analysis of the logs showed that CSR did not allow the
HotSpot session to be created because it thought another beaconing
session, namely a P2P GO session, was already active.  It turns out
that CSR utilizes a static global structure csrRoamRoamSession to
maintain per-session information.

On Product Lines where the WLAN driver is dynamically loaded this
static structure is reinitialized by the OS when the driver changes
modes of operation, since the driver will be reloaded when the mode
changes.  But when the driver is statically linked this static
structure is not reinitialized.  Hence when the driver changes from
STA + P2P mode to HotSpot mode, CSR believe P2P mode is still enabled.
Therefore modify csrRoamInitGlobals() to always initialize
csrRoamRoamSession before using it.  In addition delete two other
static structures, csrRoamPowerTableFromEeprom and
csrRoamPowerTableFromEeprom40MHz, which are no longer being used.
===