qseecom: Unload the app upon receiving qseecom_release.

Upon receiving qseecom_release() app corresponding to the app id
needs to be shutdown.This is applicable to user space clients as well.

Change-Id: Ie659a9409f8470b7ed4a5088e6779b50c5dc1cca
qseecom: Fix issue with incomplete command exiting prematurely

A process waiting on a signal can be awaken by any signals. We
need to only continue processing when the condition of the
wait event is met.

Change-Id: Ib2102babbb505876f89b04399729e6ff5a475605
qseecom: Fix issues with failure to release client handle

In some scenarios when qseecom_release is called with the incorrect
client handle type. Hence proper cleanup is not done for the memory
allocated to the device handle or to unload the app.

This change addresses the cleanup issues related to qseecom client in
qseecom_release call by ensuring the handle type is set correctly and
cleanup is done properly based on client type.

Change-Id: I126aa431ce635ae98100b774e3d92b704635d199
qseecom: Add support to handle multiple app load & unload

Media server is associated with multiple apps on TZ-side.
Unloading a single app for clean up is not enought. QSEECOM
needs to handle the app load & unload of multiple apps
associated with the client. During app_load & app_unload
along with app_id, app_name should also be checked. Besides,
keymaster will not be unloaded.

Change-Id: Iea53362a21e359e54e40a0a93688a05264cfde5c
qseecom: fix an issue related to search app when unloading an app

Make a change in qseecom_unload_app to stop the execution of app
searching when an app is founded, even if this app is in use with
ref_cnt greater than one.

Change-Id: I0328252668ef1069ec514bfb913b927a7da76594
misc: rt5501: Ensure gpio is requested before use

Change-Id: I632eb1613f6978eb33c01308de8812772649e580
msm: camera: set T6 camera hal version

Change-Id: Ia7db9dc2e8c0de3c01dbe9c43fb54b807a1675e9
radio: iris: Mark radio_hci_smd_init as __init

Change-Id: I37aba71dc5fdee00054172ed46a20d93c3e77766
radio: iris: Initialize radio-iris for built-in iris-transport

Change-Id: Id0d9a36f93ec387e08be3d041e60113d2cf75aa8
stable_kernel_rules: Add pointer to netdev-FAQ for network patches

commit b76fc285337b6b256e9ba20a40cfd043f70c27af upstream.

Change-Id: I5ad0bbfeb07c75cdc6023a01a40791a99df0e9c4
ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE

commit 9301503af016eb537ccce76adec0c1bb5c84871e upstream.

This mode is unsupported, as the DMA controller can't do zero-padding
of samples.

Change-Id: Ia5fe55dad41906131b3472d49274caa68e3752ed
ibmveth: Fix endian issues with rx_no_buffer statistic

commit cbd5228199d8be45d895d9d0cc2b8ce53835fc21 upstream.

Hidden away in the last 8 bytes of the buffer_list page is a solitary
statistic. It needs to be byte swapped or else ethtool -S will
produce numbers that terrify the user.

Since we do this in multiple places, create a helper function with a
comment explaining what is going on.

Change-Id: I1c81c42e1e5af26553ed3869b3477ad132e8ca78
HID: fix a couple of off-by-ones

commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream.

There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.

Change-Id: Ibe4b9a21f7cdd4d00484a78e4d6e283ebad50b9f
HID: logitech: perform bounds checking on device_id early enough

commit ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 upstream.

device_index is a char type and the size of paired_dj_deivces is 7
elements, therefore proper bounds checking has to be applied to
device_index before it is used.

We are currently performing the bounds checking in
logi_dj_recv_add_djhid_device(), which is too late, as malicious device
could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the
problem in one of the report forwarding functions called from
logi_dj_raw_event().

Fix this by performing the check at the earliest possible ocasion in
logi_dj_raw_event().

Change-Id: I163bd2d47d8b46bd37723294a53c42320dcb31da
isofs: Fix unbounded recursion when processing relocated directories

commit 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 upstream.

We did not check relocated directory in any way when processing Rock
Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL
entry pointing to another CL entry leading to possibly unbounded
recursion in kernel code and thus stack overflow or deadlocks (if there
is a loop created from CL entries).

Fix the problem by not allowing CL entry to point to a directory entry
with CL entry (such use makes no good sense anyway) and by checking
whether CL entry doesn't point to itself.

Change-Id: Ib072a860e49fbabe50b747f84cca3b860522bc87
MIPS: OCTEON: make get_system_type() thread-safe

commit 608308682addfdc7b8e2aee88f0e028331d88e4d upstream.

get_system_type() is not thread-safe on OCTEON. It uses static data,
also more dangerous issue is that it's calling cvmx_fuse_read_byte()
every time without any synchronization. Currently it's possible to get
processes stuck looping forever in kernel simply by launching multiple
readers of /proc/cpuinfo:

	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	...

Fix by initializing the system type string only once during the early
boot.

Change-Id: Ia6970d7daebb86b07362a9b02b3b1e6d2066d169
kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-3601)

commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.

The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.

By making gfn very large, malicious guest or userspace can cause kvm to
go to this error path, and subsequently to pass a huge value as size.
Alternatively if gfn is small, then pages would be pinned but never
unpinned, causing host memory leak and local DOS.

Passing a reasonable but large value could be the most dangerous case,
because it would unpin a page that should have stayed pinned, and thus
allow the device to DMA into arbitrary memory.  However, this cannot
happen because of the condition that can trigger the error:

- out of memory (where you can't allocate even a single page)
  should not be possible for the attacker to trigger

- when exceeding the iommu's address space, guest pages after gfn
  will also exceed the iommu's address space, and inside
  kvm_iommu_put_pages() the iommu_iova_to_phys() will fail.  The
  page thus would not be unpinned at all.

Change-Id: Ic2659f97e98386e432c0ce217c3a238758c2e65b
pata_scc: propagate return value of scc_wait_after_reset

commit 4dc7c76cd500fa78c64adfda4b070b870a2b993c upstream.

scc_bus_softreset not necessarily should return zero.
Propagate the error code.

Change-Id: Ic2ba75a8b6c7cacb483b3d7a9961b0f0ec87c207
iommu/amd: Fix cleanup_domain for mass device removal

commit 9b29d3c6510407d91786c1cf9183ff4debb3473a upstream.

When multiple devices are detached in __detach_device, they
are also removed from the domains dev_list. This makes it
unsafe to use list_for_each_entry_safe, as the next pointer
might also not be in the list anymore after __detach_device
returns. So just repeatedly remove the first element of the
list until it is empty.

Change-Id: I4f0a0969022f391cf4a100dd5ec39d6955f99435
md/raid6: avoid data corruption during recovery of double-degraded RAID6

commit 9c4bdf697c39805078392d5ddbbba5ae5680e0dd upstream.

During recovery of a double-degraded RAID6 it is possible for
some blocks not to be recovered properly, leading to corruption.

If a write happens to one block in a stripe that would be written to a
missing device, and at the same time that stripe is recovering data
to the other missing device, then that recovered data may not be written.

This patch skips, in the double-degraded case, an optimisation that is
only safe for single-degraded arrays.

Bug was introduced in 2.6.32 and fix is suitable for any kernel since
then.  In an older kernel with separate handle_stripe5() and
handle_stripe6() functions the patch must change handle_stripe6().

Change-Id: I8dbcb57cfe9fa20f52ca360e39c32cc594a264c8