Bluetooth: Many fixes.

Bluetooth: Resolved a race condition

Due to simultaneous disconnects from HCI and SCO
this race condtion arrives. While doing SCO disconnect
a null pointer check for HCI connection should be present
to avoid any crash due to this condtion.

CRs-Fixed: 415887
Change-Id: I23f0a7a256e267650db0abc2fc510b964b64c50c
Signed-off-by: Nitin Srivastava <nitinsr@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Bluetooth: Support for Remote name request cancel command

Add support for remote name request cancel command in mgmtops
plugin.

Change-Id: If8bec8b457461f7bca90af940d2473b810677322
CRs-fixed: 414884
Signed-off-by: Ram Mohan Korukonda <rkorukon@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Bluetooth: Handle pairing cancel req for LE device

When pairing is cancelled during the pass key request UI pop
up, call pairing complete after sending SMP_CMD_PAIRING_FAIL
which would clean up all the pairing callbacks and send
notification to the above layers.

Change-Id: I0d3e9bdc19dc2fcae280d3c70ddea976ecb218c7
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
CRs-fixed: 430016
Signed-off-by: Sunny Kapdi <sunnyk@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Revert "Bluetooth: Initiate dedicated bonding if pin/key missing on remote device"

Change has to be reverted to address one user interaction case,
in the process of addressing one issue it made mandate to have
user interactions in some BT scenarios, the issue is fixed via
f8fffe8423933433c30dda4f9a92afc71e8def21 and it addressees all
the user scenarios properly.

More details on this issue is provided in CR: 413132 analysis
section in the prism.

This reverts commit 45df0f99094aefc2564951495ab0005a18d62de3.

Change-Id: I56611cb2646789c71f4012e906a7bbada1236c00
Signed-off-by: Bhasker Neti <bneti@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Bluetooth: Avoid a case where sleep is getting called in soft irq context

While turning off BT, sleep is getting called in the soft isr context
from work queue which is queued from a code section guarded under the
bh lock,
To resolve this released the bh lock before queing the work, as it wont
impact any BT functionality.

CRs-fixed: 405917
Change-Id: I1b872d724b4d0d384cc5314e0f493facd9829a54
Signed-off-by: Bhasker Neti <bneti@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Bluetooth:Show bonding dialog if neither side requires no bonding

If the bonded remote device is removed from the list of paired
devices in the DUT, it is still possible to connect to the DUT
from the remote device without any user confirmation.

CRs-fixed: 413132
Change-Id: Iea3e4cf41e5403c3e304ca5f82cf42266be35b79
Signed-off-by: Bhasker Neti <bneti@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Bluetooth: Fixes FindMe Target L2CAP channel issue

When whitelist APIs are used for establishing LE connection
between the phone and remote LE device, few times
ATT requests like Read by Group Type request are received by
the phone from the remote device before the L2CAP channel has
been set up completely. Hence the LE server in the phone
sends a "Request not supported" error response since
the L2CAP channel has not yet been created. This fix checks
the state of the L2CAP channel after sleeping for a while
and sends the ATT request to be processed by the upper layers
when the L2CAP channel is up.

CRs-fixed: 415648

Change-Id: Ifbaf75fe612195b3c6ce49629106cac09dd0a437
Signed-off-by: Subramanian Srinivasan <subrsrin@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
Bluetooth: Update pending_sec_level on auth update.

Based on the user requirement for auth type, update even
the pending security level. This will make sure the authentication
requirement matches the action at kernel space on connection
establishment.

CRs-Fixed: 385463
Change-Id: I94c7e621c105bb2180e6e722cc8cca17869ff2e5
Signed-off-by: Srinivas Krovvidi <skrovvid@codeaurora.org>
Signed-off-by: Mallikarjuna GB <gbmalli@codeaurora.org>
bluetooth: LE conn whitelist implementation

Add support to create connection to LE devices using
whitelist. With this, the Controller can try to connect
to multiple devices at the same time. The following
interfaces are added.
1. Add/Remove device from whitelist
2. Clear all the devices from whitelist
3. Create Connection to devices from whitelist
4. Cancel create connection to whitelist devices

CRs-fixed: 388980
Change-Id: I3900c71255e754f80bb2873ae19a41b94cca76c3
Signed-off-by: Sunny Kapdi <sunnyk@codeaurora.org>
(cherry picked from commit 93bef895b01b79f49af60ba1394c9c3f6e563212)
(cherry picked from commit 377ee2bf1fc37bcbeae872661646bdd6a5f8da31)
Bluetooth: Fix for supervision timeout must be 6X connection interval

Added a new function to verify whether the LE Connection Update
parameters are valid instaed of verifying all the LE Connection
parameters since only update parameters are set in the Connection
Update Request.

CRs-Fixed: 387146
Change-Id: I9fe6b51e44e2793f3945613fdfde3a039804746f
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
(cherry picked from commit 95319af0612d58788279748f586cc57221c3443e)
Bluetooth: Send Disconnection reason to Bluez

Send device disconnection reason to bluez on receiving the
diconnection complete event so that low energy profiles
such as proximity can decide to reconnect if the reason
is link loss.

CRs-Fixed: 378240
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
(cherry picked from commit da09d26a75ee1c7c1911dcfbe0128fd09f6631f4)

Change-Id: Iab1fede47f44342d87be6c3c5aa7590754fd950c
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Bluetooth: Validate hci conn validity before refering wakelock.

Found in a rare case there is possibility that remote device
sent disconnect on a connection and DUT is trying send data
on the same. In that case accessing some released wakelock
is causing issue. The current changes are to use locking
mechanism to validate the connection before acting on the
wake lock.

CRs-Fixed: 394651
Change-Id: I6a4188a7d0d05a8cfbe66d3680473d549157917a
Signed-off-by: Srinivas Krovvidi <skrovvid@codeaurora.org>
(cherry picked from commit 6aadc41fcbd28dc3899a4b5d098e5f316588a029)

Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Bluetooth: Check for both SCO and ESCO types in hci_connect API.

In hci_connect API there is check for existing link, before
connect operation in order to avoid queuing connect if connection
already exist. This check for Synchronous connections is not
validating for ESCO and SCO connection types which are possible
synchronous connections.The current change takes care of verifying
both before proceeding to add a new connection.

Change-Id: I9018e0938bcd222bb6d80944e1b113e07227b066
Signed-off-by: Srinivas Krovvidi <skrovvid@codeaurora.org>
(cherry picked from commit 645f4d465ba131c87a99fdebcef5e597181b33c8)

Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Power fixes.
power: pm8921-bms: fix fake battery emulation

With the recent split of functions to calculate and report state of
charge, the faking battery feature broke, it remained in the calculate
function.

Move the fake battery feature in the reporting function, where it really
belongs.

Change-Id: I6a3fcc3b233792d87ea4ac8fe2e155e10ca24e21
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
power: pm8921-charger: fix EOC worker not starting

There are situations when we observe that charging is in progress
but the end of charge (EOC) worker is not running. This leads to
problems like
-never detecting end of charge
-not adjusting vddmax
-not preventing suspend while charging.

The reason is that the bootloader could have started charging already,
causing a fastchg interrupt to not happen. If the fastchg interrupt is
missed the driver will never start EOC worker.

Check the real time status of the fastchg interrupt and if it is fast
charging invoke the handler so that the eoc worker could be
started.

(cherry picked from commit 7f1d97fd69c3afe66577e731105207e5db544ab2)

CRs-Fixed: 393301
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>

Change-Id: I5c0ba3b8f0653c5f9d64f35346601763c059505a
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
power: pm8921-charger: Control CHG_USB_SUSPEND enabling boost

Toggle the CHG_USB_SUSPEND bit when utilizing the VBUS boost.
This bit controls ensures that no current is being drawn from
a USB device and the charger runs off the battery.

This makes sure that when pm8921_disable_source_current is called
the correct setting is written to the suspend bit depending
on the disable flag.

(cherry picked from commit d8878596b9b19668fd1f1b226a333d955f2218c4)
CRs-Fixed: 393498
Signed-off-by: David Keitel <dkeitel@codeaurora.org>

Change-Id: Iae390fd10e59d6ba1fe85743c1015eea35b06f7a
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
power: pm8921-charger: Fix bug in current limit lookup

In the usb_ma_table there exist two consecutive values
that have IUSB_FINE_RES bit set. Some functions
incorrectly assume that this does not happen.

Fix this by checking for consecutive values having
IUSB_FINE_IRES bit set.
(cherry picked from commit 67ebde08e12d246302d133b4510d59c8f96325d1)
CRs-Fixed: 404348
Signed-off-by: David Keitel <dkeitel@codeaurora.org>

Change-Id: I6b6ca96b92ec4b9765e4812352057a0ac8cff380
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
power: pm8921-charger: report DC online for some platforms.

Some hardware platforms can supply VPH_PWR without battery
or charger being present.

To avoid shutting down due to no connected power sources
from the perspective of software set a flag that forces
the DC supply to be online for this type of platform.

Signed-off-by: David Keitel <dkeitel@codeaurora.org>
(cherry picked from commit a3cf943ef8c91435e2cb94b8e8bcc482dc65cb27)

Conflicts:

	drivers/power/pm8921-charger.c

Change-Id: I565edb1ab797384481ce5e37aee73ee0a8e80428
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
3.4.0 - 3.4.49
writeback: fix writeback cache thrashing

From: Namjae Jeon <namjae.jeon@samsung.com>

Consider Process A: huge I/O on sda
        doing heavy write operation - dirty memory becomes more
        than dirty_background_ratio
        on HDD - flusher thread flush-8:0

Consider Process B: small I/O on sdb
        doing while [1]; read 1024K + rewrite 1024K + sleep 2sec
        on Flash device - flusher thread flush-8:16

As Process A is a heavy dirtier, dirty memory becomes more
than dirty_background_thresh. Due to this, below check becomes
true(checking global_page_state in over_bground_thresh)
for all bdi devices(even for very small dirtied bdi - sdb):

In this case, even small cached data on 'sdb' is forced to flush
and writeback cache thrashing happens.

When we added debug prints inside above 'if' condition and ran
above Process A(heavy dirtier on bdi with flush-8:0) and
Process B(1024K frequent read/rewrite on bdi with flush-8:16)
we got below prints:

[Test setup: ARM dual core CPU, 512 MB RAM]

[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   384 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   960 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   768 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   320 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =  1024 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   576 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   512 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB

As mentioned in above log, when global dirty memory > global background_thresh
small cached data is also forced to flush by flush-8:16.
If removing global background_thresh checking code, we can reduce cache
thrashing of frequently used small data.
And It will be great if we can reserve a portion of writeback cache using
min_ratio.

After applying patch:
$ echo 5 > /sys/block/sdb/bdi/min_ratio
$ cat /sys/block/sdb/bdi/min_ratio
5
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  84160 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  96960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  94080 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  91520 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  89600 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  72960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90688 KB

As mentioned in the above logs, once cache is reserved for Process B,
and patch is applied there is less writeback cache thrashing on sdb
by frequent forced writeback by flush-8:16 in over_bground_thresh.

After all, small cached data will be flushed by periodic writeback
once every dirty_writeback_interval.

Suggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Vivek Trivedi <t.vivek@samsung.com>
config: Remove unused MEDIA_TUNER option

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
staging: android: logger: Sync with 3.9