media: dvb: Fix error handling of SDMX API failures

When setting of key-ladder index fails, there's no need
to fail starting of the filter since it could only mean
that decryption might fail if encrypted packets are encountered.

In addition, if closing SDMX session fails, SDMX TZ application
might be removed anyhow, therefore we should clear reference
counting of SDMX session so that it is re-opened if requested
in the future.

Change-Id: I17e1ce62b72910e2086d948807af969725c6f18b
Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>
usb: chipidea: udc: fix memory access of shared memory on armv5 machines

The udc uses an shared dma memory space between hard and software. This
memory layout is described in ci13xxx_qh and ci13xxx_td which are marked
with the attribute ((packed)).

The compiler currently does not know about the alignment of the memory
layout, and will create strb and ldrb operations.

The Datasheet of the synopsys core describes, that some operations on
the mapped memory need to be atomic double word operations. I.e. the
next pointer addressing in the qhead, as otherwise the hardware will
read wrong data and totally stuck.

This is also possible while working with the current active td queue,
and preparing the td->ptr.next in software while the hardware is still
working with the current active td which is supposed to be changed:

writeb(0xde, &td->ptr.next + 0x0); /* strb */
writeb(0xad, &td->ptr.next + 0x1); /* strb */

<----- hardware reads value of td->ptr.next and get stuck!

writeb(0xbe, &td->ptr.next + 0x2); /* strb */
writeb(0xef, &td->ptr.next + 0x3); /* strb */

This appeares on armv5 machines where the hardware does not support
unaligned 32bit operations.

This patch adds the attribute ((aligned(4))) to the structures to tell
the compiler to use 32bit operations. It also adds an wmb() for the
prepared TD data before it gets enqueued into the qhead.

CRs-Fixed: 494323
Change-Id: I3fc2e0f662076572d61f97ed708026be3cd3e59c
Cc: stable <stable@vger.kernel.org> # v3.5
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: a9c174302b1590ef3ead485d804a303c5f89174b
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[pkondeti@codeaurora.org: resolved merge conflicts]
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Revert "Revert "msm: kgsl: a2xx: Check the right interrupt status bits""

This reverts commit a5f68fc646d3bfacfe50d1238f8d468181e823ec.

Change-Id: Idf587fca176c513445008fdab6dbb2c4a1f3f3e2
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
msm_fb: Correct R and G offsets for correct mapping

R and G colors are swapped when ARGC test cases are executed.
Correct the color mapping to right register offset to fix
the color swapping issue.

CRs-Fixed: 491215

Change-Id: I4997acce577bdbbdf39e22502a678dbecf0bfc37
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
msm: audio: qdsp6v2: Fix for kernel crash during stability

- Userspace calling AYSN_READ during flush, READ_DONE ack for
  this is coming after FLUSH_DONE which is hitting BUG_ON as
  buffers are removed from in_queue/out_queue during flush.
- Fix is to avoid sending READ requests to DSP until flush
  is complete.

CRs-Fixed: 485288
Change-Id: Ia2a64471a3507b3f5565b695c40cc6dd9081930d
Signed-off-by: Deepa Madiregama <dmadireg@codeaurora.org>
timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized
each time a CPU is brought up. If a CPU is brought online
during the period that another thread is trying to modify an
inactive timer on that CPU with holding its timer base lock,
then the lock will be reinitialized under its feet. This leads
to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466,
 .owner_cpu: 1
<4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>]
(do_raw_spin_unlock+0x40/0xcc)
<4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>]
(_raw_spin_unlock+0x8/0x30)
<4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>]
(mod_timer+0x294/0x310)
<4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>]
(queue_delayed_work_on+0x104/0x120)
<4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>]
(sdhci_msm_bus_voting+0x88/0x9c)
<4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>]
(sdhci_disable+0x40/0x48)
<4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>]
(mmc_release_host+0x4c/0xb0)
<4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>]
(mmc_sd_detect+0x90/0xfc)
<4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>]
(mmc_rescan+0x7c/0x2c4)
<4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>]
(process_one_work+0x27c/0x484)
<4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>]
(worker_thread+0x210/0x3b0)
<4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>]
(kthread+0x80/0x8c)
<4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>]
(kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU #3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU #2.
The code locked the timer_base corresponding to CPU #2. Before it could
proceed, CPU #2 came online and reinitialized the spinlock corresponding
to its base. Thus now CPU #3 held a lock which was reinitialized. When
CPU #3 finally ended up unlocking the old cpu_base corresponding to CPU #2,
we hit the above SPIN_BUG().

CPU #0			CPU #3				       CPU #2
------			-------				       -------
.....			 ......				      <Offline>
			mod_timer()
			 lock_timer_base
			  spin_lock_irqsave(&base->lock)

cpu_up(2)		 .....				        ......
							 init_timers_cpu()
.....		 	 spin_unlock_irqrestore(&base->lock)     ......
			   <spin_bug>

Allocation of per_cpu timer vector bases is done only once under
"tvec_base_done[]" check. In the current code, spinlock_initialization
of base->lock isn't under this check. When a CPU is up each time the base
lock is reinitialized. Move base spinlock initialization under the check.

CRs-Fixed: 471127
Change-Id: I73b48440fffb227a60af9180e318c851048530dd
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Merge "msm_fb: Correct R and G offsets for correct mapping"
Merge "msm: audio: qdsp6v2: Fix for kernel crash during stability"
Merge "usb: chipidea: udc: fix memory access of shared memory on armv5 machines"
Merge "Revert "Revert "msm: kgsl: a2xx: Check the right interrupt status bits"""
Merge "timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE"
Merge "media: dvb: Fix error handling of SDMX API failures"
msm: vidc: Handle mgen2maxi interrupt in video driver

Handle interrupt generated by mgen2maxi h/w and
avoid unknown interrupts storm which results in
target reset issues.

Change-Id: Ida24cb2dde15c9cd4a4c1d9ca336b1a4b662c4d1
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Merge "msm: vidc: Handle mgen2maxi interrupt in video driver"
ASoC: audio: Fix BE not disconnected even codec teardown

Scenario:
When FE1(LowLatency) comes in which opens BE1 and puts it in state
SND_SOC_DPCM_STATE_START. Similarly FE2(LPA) comes in with
connecting to same BE. Now FE2 is in SND_SOC_DPCM_STATE_PREPARE
state and waits for TRIGGER_START. Meanwhile FE1 is closed which
doesn't affect BE1 and FE2 which are connected.
Also, for FE2 pcm_close is called before TRIGGER_START itself.
In such a case, BE1 is not getting disconnected (afe_close is
not called) while Codec is teared down resulting in Slimbus
overflow.

Fix:
Whenever BE1 is found to be in SND_SOC_DPCM_STATE_START state
and FE1 being connected is not started yet, and close sequence
happens for this FE, then allow hw_free to happen for BE1 if
this is the only FE connected to this BE1. This allows BE to be
disconnected which calls afe_close then followed by Codec teardown
not resulting in any Slimbus overflows.

CRs-Fixed: 498206, 493781
Change-Id: I03a80a12c1fd0cf09bd2e3dfe1f1eb56589016d3
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
Merge "ASoC: audio: Fix BE not disconnected even codec teardown"