audio_policy: Fix for audio routing speaker though BT is connected

- Speaker device is selected by getDeviceForStrategy() though BT is
  connected as mA2dpSuspended is still remaining as 'true' even
  after ending the voice call.
- This flasg is not updated by checkA2dpSuspend() as force usage
  for communication and record is still FORCE_BT_SCO after ending
  voice call.
- Modified condition check to set mA2dpSuspended to 'false' as soon
  as phone state is changed to MODE_NORMAL
  porting from change:Ib3a67268be33a10c6bcdf6437868990a92a06c2f

Change-Id: I86ebb66cd165e8009bfa6193d2ad9ab383996283
CRs-Fixed: 671810
wlan: Fix for improper comparison of driver_status string

This commit ensures driver load failure status is compared with
valid string which has the failure/success information.

Change-Id: I3b619ad0c005fb793d127bd2a23b376ed961d0b7
CRs-Fixed: 652539
audio:Changes to enable LPA/Tunnel

 Changes to enable LPA/Tunnel mode

Change-Id: Ic7381c4c45b67ae0cfdcc4a01fc85014ca95dec2
audio: Add ifdefs for LPA/Tunnel

* Require QCOM_DIRECTTRACK to enable this feature.

Change-Id: I8d698b7fef6da09378a965be1f500de2eacce7c9
libhardware_legacy: Add MSM specific flags, devices and channels.

- Add support for MSM flags, devices and channels

Change-Id: I6cb5f34b49e24e6d6f97821189bdb6e96ce283a8
audio: Add ifdefs for MSM specific flags

* Require QCOM_HARDWARE to enable these flags.

Change-Id: Ia20602ac31d7e192c71b48ad21d4112d5af273c6
wifi: support adding p2p0 when starting wpa_supplicant

For TI wlan chips in p2p mode we need this omapzoom cherry-pick
to start p2p0 correctly.

http://www.omapzoom.org/?p=platform/hardware/libhardware_legacy.git;a=commit;h=ccb4c24db795059f1df365d313d80c6b269bc55e
By: Arik Nemtsov <arik@wizery.com>
On: Tue, 31 Jul 2012 21:21:20

Original commit description:
Add p2p0 using an NL80211 command when wpa_supplicant is started, and
p2p_supported is enabled.

Change-Id: Ibc0ad138513f024672642cc5764a81510aa38625
Signed-off-by: Hashcode <hashcode0f@gmail.com>

From: Barak Bercovitz <barak@wizery.com>
Date: Fri, 18 Oct 2013 12:41:32 +0300
Subject: [PATCH] wifi: remove p2p interface on supplicant stop

wifi: remove p2p interface on supplicant stop

remove p2p interface on wpa_supplicant stop
so next time it is started it won't fail when trying
to create p2p again

Change-Id: I7a4c5e9a82a013afc75548d175d5850d67fcd927
wifi: Choose correct nvram file on samsung hardware

Change-Id: I9d428ae61c1ce80d97e6ea513839ed64e8f61440
wifi: Add support for AP module args

 * Needed for Samsung's goofy handling of AP mode

Change-Id: I5ec65460b7c9f8ef34170473cf1bdaa36587767b
wifi: fix samsung wifi logic

Change-Id: Ib065c0dffa1265a17f5e4fd6ec0b0ad36bbc7b14
wifi: add support for semcosh nvram

Change-Id: I272607b2835c5df97b8e175a9bcd559b3ec1a105
uevent: Allow multiple uevent listeners from the same process

The netlink socket created by uevent_init sets the nl_pid to the
current PID. nl_pid must be unique per-process, however it does not
have to do with the PID. From the documentation:

"
For a user-space process, nl_pid
is usually the PID of the process owning the destination socket.
However, nl_pid identifies a netlink socket, not a process.  If a
process owns several netlink sockets, then nl_pid can be equal to the
process ID only for at most one socket.
"

In use cases where a single process calls uevent_init more than one
time, the second one will always fail. This patch sets the nl_pid
to 0, which lets the kernel pick its own unique identifier as per the
documentation:

"
If the application sets it to 0, the kernel takes
care of assigning it.  The kernel assigns the process ID to the first
netlink socket the process opens and assigns a unique nl_pid to every
netlink socket that the process subsequently creates.
"

The behavior stays the same for the first socket but will also succeed
in subsequent calls.

Change-Id: I6fa74adc9d5835ff39b86187799998111fc12001
(cherry picked from commit 6dcd02055aaa2ce1e7132d5886557a7a5be6571f)
Check for monitor_conn existence before accessing the same

Monitor_conn socket gets closed by wifistatemachine and thus
accessing the same in WiFiMonitor thread results in a crash.
Hence check for the same before accessing the same.

Change-Id: I15024fa5324187c6e8dbd483238bfbeea7c4c016
CRs-Fixed: 590655