Bluetooth: Remove unused hci_le_ltk_reply()
In this API, we were using sizeof operator for an array
given as function argument, which is invalid.
However this API is not used anywhere.

Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
_____________

Bluetooth: Remove unused hci_le_ltk_neg_reply()
No one is using hci_le_ltk_neg_reply() in bluetooth subsystem.

Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
sched: disable gentle fair sleepers
ARM: net: JIT compiler for packet filters enabled by default
thanks to faux123
crypto: msm: update Qualcomm Crypto Engine (QCE) from CAF msm-3.4
char: hw_random: update Qualcomm HW RNG from CAF msm-3.4
enabled Qualcomm Crypto Accelerator
ARM: hw_breakpoint: enable HAVE_HW_BREAKPOINT feature flag
HAVE_HW_BREAKPOINT was disabled temporarily from commit
480a82f59712136b51ee5ca05c4f22c1738010c5. Issue not seen with the
latest kernel hence re-enable the feature and fix merge issue from
previous kernel upgrade.

Change-Id: Ia6e7e8282c848dd73108e4d951b3375bb7caa63c
Signed-off-by: Jin Hong <jinh@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
________________

ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
The reset value of the BCR, BVR, WCR, and WVR registers are all
UNKNOWN on ARMv7. Unfortunately, reset_ctrl_regs() clears these
registers *after* enabling monitor mode, not before, and so some
implementations may experience UNPREDICTABLE behavior if the
reset values of these registers are non-zero. Clear the
breakpoints before enabling monitor mode so that we don't
experience boot hangs/loops due to breakpoints being enabled
out of reset.

Change-Id: I029fbe40725e803183544ddd6fe40285de4137e8
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
update defconfig
workqueue: cond_resched() after processing each work item
commit b22ce27 upstream.

If !PREEMPT, a kworker running work items back to back can hog CPU.
This becomes dangerous when a self-requeueing work item which is
waiting for something to happen races against stop_machine.  Such
self-requeueing work item would requeue itself indefinitely hogging
the kworker and CPU it's running on while stop_machine would wait for
that CPU to enter stop_machine while preventing anything else from
happening on all other CPUs.  The two would deadlock.

Jamie Liu reports that this deadlock scenario exists around
scsi_requeue_run_queue() and libata port multiplier support, where one
port may exclude command processing from other ports.  With the right
timing, scsi_requeue_run_queue() can end up requeueing itself trying
to execute an IO which is asked to be retried while another device has
an exclusive access, which in turn can't make forward progress due to
stop_machine.

Fix it by invoking cond_resched() after executing each work item.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Jamie Liu <jamieliu@google.com>
References: http://thread.gmane.org/gmane.linux.kernel/1552567
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>