wlan: memory corruption fix

During unload WLAN driver, MSG Q flushing routine will free memory
which is not dynamically allocated.
Then memory area corruption happpen, and when next load driver,
corrupted memory will be allocated, as a result system crash happen.
Not to free static memory location, MSG body for MC thread WDI Q
will not be freed, and will print message type which made problem.

Change-Id: Ib6797be3ddc60a3734c3608963f3fdedb2631bea
CRs-fixed: 589882
wlan: release the nv while unloading but not while doing an SSR

The nv data structures have to be released while unloading the
driver to prevent memory leaks, but while doing a subsystem restart
(SSR) do not release the nv during the shutdown procedures, this
way we dont have to load the nv again and it will save the restart
time.

Change-Id: I99f53144a817ac1e61fe789a839dc56791a51475
CRs-Fixed: 591220
P2P: Sanity check for presence of SSID in p2p scan request.

In Change-Id I7d810255a70e5d7e9ae143e094c878f08b2a829d, we
are increasing the dwell time of p2p scan if the p2p scan
is for specific SSID.
There may be chances that some supplicants doesn't trigger
p2p scan for specific SSID or SSIDList is NULL.
This results in kernel panic when p2p scan is issued to
establish p2p connection.

To resolve this issue, the number of SSIDs in scan request
is checked for the presence of SSID in p2p scan request.

CRs-fixed: 591975
Change-Id: I17cd4c5375e45ccb4b407388a51ee068872dc2f9
wlan: Use spinlock to synchronize SME request/response

Many of the APIs supported by HDD require a call to SME to perform an
action or to retrieve some data.  In most cases SME performs the
operation asynchronously, and will execute a provided callback
function when the request has completed.  In order to synchronize this
the HDD API allocates a context which is then passed to SME, and which
is then, in turn, passed back to the callback function when the
operation completes.  The callback function then sets a completion
variable inside the context which the HDD API is waiting on.  In an
ideal world the HDD API would wait forever (or at least for a long
time) for the response to be received and for the completion variable
to be set.  However in most cases these HDD APIs are being invoked in
the context of a userspace thread which has invoked either a cfg80211
API or a wireless extensions ioctl and which has taken the kernel
rtnl_lock.  Since this lock is used to synchronize many of the kernel
tasks, we do not want to hold it for a long time.  In addition we do
not want to block userspace threads (such as the wpa supplicant's main
thread) for an extended time.  Therefore we only block for a short
time waiting for the response before we timeout.  This means that it
is possible for the HDD API to timeout, and for the callback to be
invoked afterwards.  In order for the callback function to determine
if the HDD API is still waiting, a magic value is also stored in the
shared context.  Only if the context has a valid magic will the
callback routine do any work.

The original implementation of this logic included a well-documented
race condition where the HDD API timeout could coincide with the
callback being invoked.  In such a scenario the HDD API could be
invalidating the context immediately after the callback function had
validated it and was dereferencing it.  In order to mitigate the
effects of such a race condition, the HDD API would always msleep()
for a short amount of time when a timeout occurred so that if the
callback was executing concurrently, the callback could (hopefully)
complete its work before the HDD API exited.

Due to an customer-observed issue this logic was further scrutinized
and it was suggested that a spinlock could be used to properly
serialize the activities of the HDD API and the callback function when
they are running in parallel.  So introduce a spinlock that is used so
that if any HDD API timeout coincides with its callback, the
operations of the two threads will be serialized.

Change-Id: If0d84e535f6cf0818410e4210f5bfe8294919526
CRs-fixed: 592261
wlan: Connection Failure Event to Supplicant

Send the connection failure result up to supplicant only
when CSR has completed all the available candidate AP's
for the required profile.For each individual connection
failure the roam status would be eCSR_ROAM_ASSOCIATION_COMPLETION
and roam result would be eCSR_ROAM_RESULT_NOT_ASSOCIATED.Once
all the available AP's are tried and was not able to connect to
any of them succesfully, then the roam status would be
eCSR_ROAM_ASSOCIATION FAILURE. So, wait until the DUT/driver has
tried to connect to all the available Access Points.

Change-Id: Ic6e820ee505d4473090a5be723fa8a6f4a7a26ad
CRs-Fixed: 591082
wlan: Avoid unsafe channel FW common

If FW sends unsafe channel detect indication,
Softap mode and P2PGO mode, should avoid to stay unsafe channels.
Make indication path from FW.
Store into module context.
Store into static module storage incase of re-load driver.
Channel selection should avoid unsafe channel

Change-Id: I318b9adef8780d1e104179800f2b67a34e0dddf8
CRs-fixed: 576020
wlan: Get Mac addr from platform driver

Read the MAC address from the platform driver preferrably and
fall back to the option of auto generating the same, if the
MAC read is invalid.

Change-Id: I3f5dc5f7b3f4788c237995a34c06c7908e489c5c
CRs-Fixed: 583465
wlan: During SSR ensure that driver threads complete their work

TX, RX and MC Threads should complete exexution before
the exit routine tries to free the dynamic data these threads
are trying to process. The current implementation does an
interruptible wait for completion of the threads; but it has been
observed that if the process which initiated the driver unload
receives SIGKILL while waiting for threads to complete, the process
will continue without waiting for threads to complete and the threads
will try to access invalidated data after the module has been removed
leading to a kernel panic. To fix this make the wait uninterruptible
during SSR and ensure that the driver threads complete execution
before the driver exits.

Change-Id: Ib79e38e2ab1810b2a61c57c155ce099b0468e311
CRs-Fixed: 590623
wlan: increase MAX_CFG_INI_ITEMS to 512

Currently when the driver loads it logs an error that
MAX_CFG_INI_ITEMS is too small.  So increase the value to compensate
for the configuration items that have been recently added and to allow
some future growth as well.

Change-Id: I3e091d637560ce8ee9c5e775c739e431339bbda7
CRs-fixed: 591510
Register IPv4 notifier to notify change in IP.

Detect IPv4 address change during suspend state and reconfigure
the ARP filters to the firmware.

Change-Id: I8df10c6ef1d7be81dfd39ace268474bab6b4b353
CRs-Fixed: 587415

Conflicts:
	prima/CORE/HDD/inc/wlan_hdd_power.h
wlan: Update cfg database with passive scan dwell times

The lim layer reads the passive scan dwell time values from the
cfg database, but this database is not updated when the
passive scan dwell time values are changed in the ini file.
Hence, update the same in the database.

Change-Id: I6b1d979287183c1512243b3b485cd289fe37d5a4
CRs-Fixed: 590620
Wlan: Revision 3.2.3.208a

Revision 3.2.3.208a