power: qpnp-bms: clamp for SOC <= 0

In some scenarios a negative soc may be calculated even
though VBAT is above the cutoff voltage.

The clamping function does not take negative SOC values
into account and fails to clamp the SOC. Fix this
by checking for SOC values <= 0.

CRs-Fixed: 623091
Change-Id: I8d64b3c8717e8088be71d84d66225512b85e87e3
Signed-off-by: David Keitel <dkeitel@codeaurora.org>
ASoC: msm: qdsp6v2: Fix ion_import failure

When ion_import_legacy api fails,we should not
destory the client instead just bail out.

CRs-Fixed: 620370
Change-Id: Icbcf4dadd5f00e1cf4d7a356ee1c0f5835dcb4c4
Signed-off-by: Anish Kumar <kanish@codeaurora.org>
Merge "power: qpnp-bms: clamp for SOC <= 0"
staging: android: ashmem: Avoid deadlock with mmap/shrink

Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may
be possible for ashmem_mmap to invoke ashmem_shrink:

-000|mutex_lock(lock = 0x0)
-001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again
-002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages
-002|=
-002|124)
-003|try_to_free_pages(zonelist = 0x0, ?, ?, ?)
-004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist =
-004|0xC11D0940,
-005|new_slab(s = 0xE4841E80, ?, node = -1)
-006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags =
-006|2148925462, ad
-007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208)
-008|shmem_alloc_inode(?)
-009|alloc_inode(sb = 0xE480E800)
-010|new_inode_pseudo(?)
-011|new_inode(?)
-012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags =
-012|187)
-013|shmem_file_setup(?, ?, flags = 187)
-014|ashmem_mmap(?, vma = 0xC5D64210) <---- Acquire ashmem_mutex
-015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472,
-015|flags = 57,
-016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd =
-016|157, pgoff
-017|ret_fast_syscall(asm)
-->|exception
-018|NUR:0x40097508(asm)
---|end of frame

Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex
is already held, do not attempt to shrink.

Change-Id: I222bbf55856d5849da813b730de0636c80966c8e
CRs-Fixed: 608832
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Merge "ASoC: msm: qdsp6v2: Fix ion_import failure"
cpufreq: Fix policy getting stuck when user & kernel min/max don't overlap

Every __cpufreq_set_policy starts with checking the new policy min/max has
some overlap with the current policy min/max. This works out fine until we
end up with the policy min/max being set to a range that doesn't overlap
with the user policy min/max. Once we get into this situation, the check at
the start of __cpufreq_set_policy fails and prevents us from getting out of
this state.

This only happens when one of the CPUFREQ_ADJUST/CPUFREQ_INCOMPATIBLE
notifiers called inside __cpufreq_set_policy pick a min/max outside the
range of user policy min/max.

The real intent of the check at the start of __cpufreq_set_policy is to
make sure userspace can't set user policy min > user policy max. Since
__cpufreq_set_policy always gets called only with current user policy
min/max except when the actual user space policy min/max is changed, we can
fix the issue by simply checking the new policy min/max against current
user policy min/max.

Change-Id: Iaac805825e64d7985c41fb9052bd96baacdf3d6f
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
spi_qsd: Remove duplicate Free Chip Select GPIO

Chip select GPIO can be  free during the suspend.
Duplicate chip select  free causing RX SPI data
Corruption recently reported from customers, this
Patch corrects this.

CRs-Fixed: 626641
Change-Id: Ib80516b6d43c7185586a8815c4430446a9e31ce0
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
Merge "spi_qsd: Remove duplicate Free Chip Select GPIO"
Merge "staging: android: ashmem: Avoid deadlock with mmap/shrink"
Merge "cpufreq: Fix policy getting stuck when user & kernel min/max don't overlap"