spi_qsd: Remove check for unaligned  length during input_irq.

QUP_IRQ  complete is triggered  before  dmov_rx callback.
Which will initiate SPI to start next transfer, due to
this earlier DMOV_CMD is blocked  and results in kernel panic.

Current  Implementation  make sure that transfer complete waits
For  DMOV callback only in case of aligned lengths , This patch
ensures   transfer trigger only after DMOV  RX call back for
unaligned length also.

CRs-Fixed: 583126
Change-Id: I090cf9f2c0abb21907cf5786829d5351c23a9314
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
Asoc:msm:Added Buffer overflow check

The overflow check is required to ensure that user space data
in kernel may not go beyond buffer boundary.

Change-Id: I79b7e5f875fadcaeceb05f9163ae3666d4b6b7e1
CRs-Fixed: 563086
Signed-off-by: Mohammad Johny Shaik <mjshai@codeaurora.org>
Revert "ashmem: avoid deadlock between read and mmap calls"

This reverts commit cd9c067039e5f1acf8cb2442e96ecac9ddd25c66.
staging: android: ashmem: get_name,set_name not to hold ashmem_mutex

Problem:
There exists a path in ashmem driver that could lead to acquistion
of mm->mmap_sem, ashmem_mutex in reverse order. This could lead
to deadlock in the system.
For Example, assume that mmap is called on a ashmem region
in the context of a thread say T1.
 sys_mmap_pgoff (1. acquires mm->mmap_sem)
  |
   --> mmap_region
 	|
         ----> ashmem_mmap (2. acquires asmem_mutex)
 Now if there is a context switch after 1 and before 2,
 and if another thread T2 (that shares the mm struct) invokes an
 ioctl say ASHMEM_GET_NAME, this can lead to the following path

ashmem_ioctl
  |
  -->get_name (3. acquires ashmem_mutex)
	|
	---> copy_to_user (4. acquires the mm->mmap_sem)
Note that the copy_to_user could lead to a valid fault if no
physical page is allocated yet for the user address passed.
Now T1 has mmap_sem and is waiting for ashmem_mutex.
and T2 has the ashmem_mutex and is waiting for mmap_sem
Thus leading to deadlock.

Solution:
Do not call copy_to_user or copy_from_user while holding the
ahsmem_mutex. Instead copy this to a local buffer that lives
in the stack while holding this lock. This will maintain data
integrity as well never reverse the lock order.

Testing:
Created a unit test case to reproduce the problem.
Used the same to test this fix on kernel version 3.4.0
Ported the same patch to 3.8

Change-Id: Ia0f883e90107665981de485b41040a68db9a686e
Signed-off-by: Shankar Brahadeeswaran <shankoo77@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Satish Kamuju <skamuj@codeaurora.org>
ashmem: avoid deadlock between read and mmap calls

Avoid holding ashmem_mutex across code that can page fault.  Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex.  The reversed
order of locking between the two can deadlock.

The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls.  Move the code that accesses userspace pages
outside the ashmem_mutex.

Bug: 9261835

Conflicts:
	drivers/staging/android/ashmem.c

Change-Id: If1322e981d29c889a56cdc9dfcbc6df2729a45e9
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Satish Kamuju <skamuj@codeaurora.org>
workqueue: Added null check and warning

If work item is already in queue get_work_cwq() will return null.
so null check is added to avoid crash in delayed_work_timer_on()

CRs-Fixed: 586162

Change-Id: I5c885142fd72781cea90d6c9b3456ecc7f0778b6
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
idr: fix a subtle bug in idr_get_next()

The iteration logic of idr_get_next() is borrowed mostly verbatim from
idr_for_each().  It walks down the tree looking for the slot matching
the current ID.  If the matching slot is not found, the ID is
incremented by the distance of single slot at the given level and
repeats.

The implementation assumes that during the whole iteration id is aligned
to the layer boundaries of the level closest to the leaf, which is true
for all iterations starting from zero or an existing element and thus is
fine for idr_for_each().

However, idr_get_next() may be given any point and if the starting id
hits in the middle of a non-existent layer, increment to the next layer
will end up skipping the same offset into it.  For example, an IDR with
IDs filled between [64, 127] would look like the following.

          [  0  64 ... ]
       /----/   |
       |        |
      NULL    [ 64 ... 127 ]

If idr_get_next() is called with 63 as the starting point, it will try
to follow down the pointer from 0.  As it is NULL, it will then try to
proceed to the next slot in the same level by adding the slot distance
at that level which is 64 - making the next try 127.  It goes around the
loop and finds and returns 127 skipping [64, 126].

Note that this bug also triggers in idr_for_each_entry() loop which
deletes during iteration as deletions can make layers go away leaving
the iteration with unaligned ID into missing layers.

Fix it by ensuring proceeding to the next slot doesn't carry over the
unaligned offset - ie.  use round_up(id + 1, slot_distance) instead of
id += slot_distance.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: David Teigland <teigland@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Change-Id: Ifb6d64747e7f08e2f5d7609bd66a48405f0c9b95
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
csdio: Remove the driver

The driver is a legacy driver that is not used any longer
and its implementation is neither correct nor compiles.

Change-Id: I9862c0f93ccad6079a616f6997987d4e187a137c
Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>
netfilter: x_tables: fix ordering of jumpstack allocation and table update

During kernel stability testing on an SMP ARMv7 system, Yalin Wang
reported the following panic from the netfilter code:

  1fe0: 0000001c 5e2d3b10 4007e779 4009e110 60000010 00000032 ff565656 ff545454
  [<c06c48dc>] (ipt_do_table+0x448/0x584) from [<c0655ef0>] (nf_iterate+0x48/0x7c)
  [<c0655ef0>] (nf_iterate+0x48/0x7c) from [<c0655f7c>] (nf_hook_slow+0x58/0x104)
  [<c0655f7c>] (nf_hook_slow+0x58/0x104) from [<c0683bbc>] (ip_local_deliver+0x88/0xa8)
  [<c0683bbc>] (ip_local_deliver+0x88/0xa8) from [<c0683718>] (ip_rcv_finish+0x418/0x43c)
  [<c0683718>] (ip_rcv_finish+0x418/0x43c) from [<c062b1c4>] (__netif_receive_skb+0x4cc/0x598)
  [<c062b1c4>] (__netif_receive_skb+0x4cc/0x598) from [<c062b314>] (process_backlog+0x84/0x158)
  [<c062b314>] (process_backlog+0x84/0x158) from [<c062de84>] (net_rx_action+0x70/0x1dc)
  [<c062de84>] (net_rx_action+0x70/0x1dc) from [<c0088230>] (__do_softirq+0x11c/0x27c)
  [<c0088230>] (__do_softirq+0x11c/0x27c) from [<c008857c>] (do_softirq+0x44/0x50)
  [<c008857c>] (do_softirq+0x44/0x50) from [<c0088614>] (local_bh_enable_ip+0x8c/0xd0)
  [<c0088614>] (local_bh_enable_ip+0x8c/0xd0) from [<c06b0330>] (inet_stream_connect+0x164/0x298)
  [<c06b0330>] (inet_stream_connect+0x164/0x298) from [<c061d68c>] (sys_connect+0x88/0xc8)
  [<c061d68c>] (sys_connect+0x88/0xc8) from [<c000e340>] (ret_fast_syscall+0x0/0x30)
  Code: 2a000021 e59d2028 e59de01c e59f011c (e7824103)
  ---[ end trace da227214a82491bd ]---
  Kernel panic - not syncing: Fatal exception in interrupt

This comes about because CPU1 is executing xt_replace_table in response
to a setsockopt syscall, resulting in:

	ret = xt_jumpstack_alloc(newinfo);
		--> newinfo->jumpstack = kzalloc(size, GFP_KERNEL);

	[...]

	table->private = newinfo;
	newinfo->initial_entries = private->initial_entries;

Meanwhile, CPU0 is handling the network receive path and ends up in
ipt_do_table, resulting in:

	private = table->private;

	[...]

	jumpstack  = (struct ipt_entry **)private->jumpstack[cpu];

On weakly ordered memory architectures, the writes to table->private
and newinfo->jumpstack from CPU1 can be observed out of order by CPU0.
Furthermore, on architectures which don't respect ordering of address
dependencies (i.e. Alpha), the reads from CPU0 can also be re-ordered.

This patch adds an smp_wmb() before the assignment to table->private
(which is essentially publishing newinfo) to ensure that all writes to
newinfo will be observed before plugging it into the table structure.
A dependent-read barrier is also added on the consumer sides, to ensure
the same ordering requirements are also respected there.

CRs-Fixed: 591149

Change-Id: Ica3ec69cd6e2f77945a1a7303f92887feecf42e9
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reported-by: Wang, Yalin <Yalin.Wang@sonymobile.com>
Tested-by: Wang, Yalin <Yalin.Wang@sonymobile.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Git-commit: b416c144f46af1a30ddfa4e4319a8f077381ad63
Git-repo: https://www.codeaurora.org/cgit/quic/la/kernel/msm/common/
Signed-off-by: Vijaya Kumar T M <vtmuni@codeaurora.org>
Revert "msm_fb: display: Program TILE video frame size in dma ISR"

This reverts commit 472d090f0b745f09d515b81961291971996b6fd3.

Change-Id: Ic38c8d634cec7200df58dcf108b4f37b4fe06f70
Signed-off-by: raghavendra ambadas <rambad@codeaurora.org>
Revert "video: msm: Use the new fence release logic for video panel too"

This reverts commit 2300cc1f655670c71abf3d2c52c8875d1911b115.
msm: rpm: do not disable the interupt during suspend

If an edge wake up interrupt happens during suspend path,
the flow handler will mask it and set as pending. This
lead to suspend sequence abort when the check for all
pending edge interrupt happens. Do not disable the
interrupt (wake up interrupt to CPU0 in krait SS, #54)
during suspend.

CRs-fixed: 583318
Change-Id: I3a5afec98d445da2dfc1f16fc20d9f3e96acc17f
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
msm: ehci-hsic: Add support to disable internal clock gating

EHCI cores on latest MSMs have internal clock gating enabled
by default. Stability issues (random enumeration failures)
have been observed with some CORES where clock gating feature
doesn't work as expected. Hence add support to disable clock
gating in hardware.

Change-Id: I5209a68409ad04cba53c14c0e813aa0b925cf98e
CRs-Fixed: 538509
Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
cfg80211: discard regulatory hints from country IEs with undefined wiphy

Regulatory hints are processed in a worker thread and by the
time this thread gets a chance to schedule driver can deregister
the wiphy on which the country IE was discovered. There is no need
to process the hints which are coming from such invalid wiphy
devices and we should drop them.

Change-Id: I44f6f7b29ed1d0927151a88f3ea9e0c17044bd7e
CRs-Fixed: 588103
Signed-off-by: Mihir Shete <smihir@codeaurora.org>
msm: msm_fb: Update panel info in case of resolution change.
In case of resolution change, panel_info and mfd are updated with latest resolution.

Change-Id: I4958b8adc1650ec01c331b1a1ab695c5fd5add9b
Signed-off-by: raghavendra ambadas <rambad@codeaurora.org>
ARM: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUv6+ && MMU

Modern ARM CPUs can perform efficient unaligned memory accesses in
hardware and this feature is relied up on by code such as the dcache
word-at-a-time name hashing.

Change-Id: I41559fc9255229e2601f4bef28aa8d48246156b7
Signed-off-by: Will Deacon <will.deacon@arm.com>
update