ASoc: msm: qdsp6v2: Fix for NULL check

- Required check added for NULL pointer

CRs-fixed: 583939
Change-Id: I8b079c42ef06af9a817dc830c5f2d3c785232aa7
Signed-off-by: Mingming Yin <mingming@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
block: do not notify urgent request, when flush with data in flight

MMC device driver implements URGENT request execution with priority
(using stop flow), as a result currently running (and prepared) request
may be reinserted back into I/O scheduler. This will break block layer
logic of flushes (flush request should not be inserted into I/O scheduler).

Block layer flush machinery keep q->flush_data_in_flight list updated with
started but not completed flush requests with data (REQ_FUA).

This change will not notify underling block device driver about pending
urgent request during flushes in flight.

Change-Id: I8b654925a3c989250fcb8f4f7c998795fb203923
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: queue: do not clean current request when urgent in progress

As a result of following fix: "mmc: core: do not reinsert prepeared
FUA and FLUSH requests in stop flow" REQ_FUA and REQ_FLUSH requests
are not reinserted back into i/o scheduler, but instead started request
execution.

This change will prevent cleaning current request pointer for such
requests.

Change-Id: I25f8706954fb538be62182c87d5fb20354696b7a
CRs-fixed: 600127
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: convert WARN_ON() to printk_sched() in try_to_wake_up_local()

try_to_wake_up_local() is called with the rq lock held. Printing to
console in this context can result in a deadlock if klogd needs to
be woken up. Print to the kernel log buffer via printk_sched()
instead which avoids the wakeup.

Change-Id: Ia07baea3cb7e0b158545207fdbbb866203256d3c
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Asoc: wcd9xxx: Avoid unnecessary dispatch of mechanical interrupts

Interrupt number for WCD9306_IRQ_MBHC_JACK_SWITCH and
WCD9320_IRQ_EAR_PA_STARTUP is same due to this single interrupt is
dispatched twice, due to this real interrupts are not getting handled.
To avoid this remove WCD9320_IRQ_EAR_PA_STARTUP from interrupt table.

CRs-Fixed: 589453
Change-Id: Id1945bb6399bc9b3f991ffc587b83ca02dd9647d
Signed-off-by: Yeleswarapu, Nagaradhesh <nagaradh@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ASoC: msm: qdsp6v2: fix slow_talk not disabled issue

If slow talk is disabled from the settings menu after voice
call is ended, the command is not sent to dsp since the voc state
is not in VOC_RUN and on next call CVS still has slow talk property
enabled. Fix by disabling slow talk when voice call is ended.

CRs-Fixed: 607911
Change-Id: I2c312e41b14fca021f8d41380c3b5c8493710255
Signed-off-by: Shiv Maliyappanahalli <smaliyap@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: kgsl: Change the pagefault policy immediately

When changing the pagefault policy the MMU setting for the pagefault
policy was not changed, add code to do that.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/gpu/msm/adreno.c

Change-Id: I3b185a7f6bdda42856c777c60ae82c32b9c52eb9
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: rpm-regulator-smd: fix request suppression policy

The rpm-regulator-smd driver sends requests for a given regulator to
the RPM only if the regulator has been enabled by a Linux consumer.
If the regulator is disabled from Linux's point of view, then voltage
and current requests are buffered until the regulator is enabled again.
This buffering can lead to regulators being left at unnecessarily high
voltages when they are no longer needed.

Modify the request suppression policy so that current and voltage updates
are suppressed only before the first enable/disable request is sent for a
regulator or while the regulator is disabled if it has been marked as
apps-only. The first request sent for a given regulator must provide a
value for the enable/disable parameter otherwise the RPM will treat it as
an implicit disable request. This would break use-cases that require
certain regulators to be left on until sufficient software control is
initialized. Add a new device tree property, qcom,apps-only, which can be
used to specify that a given regulator supplies hardware that is fully
controlled by the applications processor.

CRs-Fixed: 533263
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
Change-Id: I2a8820662e1471e5ff44f7d681d5d768da74980f
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
lib/scatterlist: error handling in __sg_alloc_table()

I was reviewing code which I suspected might allocate a zero size SG
table.  That will cause memory corruption.  Also we can't return before
doing the memset or we could end up using uninitialized memory in the
cleanup path.

Change-Id: Icee6be8ea22644d7f16264d9d2a0887c7145996b
CRs-Fixed: 611562
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: 7587/1: implement optimized percpu variable access

Use the previously unused TPIDRPRW register to store percpu offsets.
TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.

This replaces 2 loads with a mrc instruction for each percpu variable
access. With hackbench, the performance improvement is 1.4% on Cortex-A9
(highbank). Taking an average of 30 runs of "hackbench -l 1000" yields:

Before: 6.2191
After: 6.1348

Will Deacon reported similar delta on v6 with 11MPCore.

The asm "memory clobber" are needed here to ensure the percpu offset
gets reloaded. Testing by Will found that this would not happen in
__schedule() which is a bit of a special case as preemption is disabled
but the execution can move cores.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ASoC: wcd9xxx: Do not use dapm to power up cdc-vdd-mic-bias

Do not use alsa dapm to power up cdc-vdd-mic-bias power supply.
Due to sound card is not initialized, powering up this dapm widget
would get delayed. This leads to wrong mbhc calibration values.

Change-Id: I4e1f3cf523ea9f771b9993317dfd515def2b0615
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ASoC: wcd9xxx: Do not acquire codec resource lock to get hph impedance

Acquiring codec resource lock within get impedance function may
cause deadlock when headset inserted/removed repeatedly. Remove
the lock as it is not required to be protected with a mutex.

CRs-fixed: 597226
Change-Id: I20865e0b2bb193f2f8777f2b69e735a0d4997cca
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Revert "ASoC: msm: qdsp6v2: disable OCMEM by default"

This reverts commit c7dbbcf2a34c9ec7bf5ca2b474649908a48b2ecf.
Revert changes to disable OCMEM for Audio and Voice use-cases
by default.

Change-Id: I814efe272c8051417753bae2fc6fe805bd817921
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
SELinux: Fix memory leak upon loading policy

commit 8ed814602876bec9bad2649ca17f34b499357a1c upstream.

Hello.

I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .

[  681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

Below is a patch, but I don't know whether we need special handing for undoing
ebitmap_set_bit() call.
----------
>>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon, 6 Jan 2014 16:30:21 +0900
Subject: SELinux: Fix memory leak upon loading policy

Commit 2463c26d "SELinux: put name based create rules in a hashtable" did not
check return value from hashtab_insert() in filename_trans_read(). It leaks
memory if hashtab_insert() returns error.

  unreferenced object 0xffff88005c9160d0 (size 8):
    comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
    hex dump (first 8 bytes):
      57 0b 00 00 6b 6b 6b a5                          W...kkk.
    backtrace:
      [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
      [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
      [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
      [<ffffffff812b345c>] security_load_policy+0x6c/0x500
      [<ffffffff812a623c>] sel_write_load+0xac/0x750
      [<ffffffff811eb680>] vfs_write+0xc0/0x1f0
      [<ffffffff811ec08c>] SyS_write+0x4c/0xa0
      [<ffffffff81690419>] system_call_fastpath+0x16/0x1b
      [<ffffffffffffffff>] 0xffffffffffffffff

However, we should not return EEXIST error to the caller, or the systemd will
show below message and the boot sequence freezes.

  systemd[1]: Failed to load SELinux policy. Freezing.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled

commit e221d028bb08b47e624c5f0a31732c642db9d19a upstream.

Root task group bandwidth replenishment must service all CPUs, regardless of
where the timer was last started, and regardless of the isolation mechanism,
lest 'Quoth the Raven, "Nevermore"' become rt scheduling policy.

Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1344326558.6968.25.camel@marge.simpson.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched/rt: Avoid updating RT entry timeout twice within one tick period

commit 57d2aa00dcec67afa52478730f2b524521af14fb upstream.

The issue below was found in 2.6.34-rt rather than mainline rt
kernel, but the issue still exists upstream as well.

So please let me describe how it was noticed on 2.6.34-rt:

On this version, each softirq has its own thread, it means there
is at least one RT FIFO task per cpu. The priority of these
tasks is set to 49 by default. If user launches an RT FIFO task
with priority lower than 49 of softirq RT tasks, it's possible
there are two RT FIFO tasks enqueued one cpu runqueue at one
moment. By current strategy of balancing RT tasks, when it comes
to RT tasks, we really need to put them off to a CPU that they
can run on as soon as possible. Even if it means a bit of cache
line flushing, we want RT tasks to be run with the least latency.

When the user RT FIFO task which just launched before is
running, the sched timer tick of the current cpu happens. In this
tick period, the timeout value of the user RT task will be
updated once. Subsequently, we try to wake up one softirq RT
task on its local cpu. As the priority of current user RT task
is lower than the softirq RT task, the current task will be
preempted by the higher priority softirq RT task. Before
preemption, we check to see if current can readily move to a
different cpu. If so, we will reschedule to allow the RT push logic
to try to move current somewhere else. Whenever the woken
softirq RT task runs, it first tries to migrate the user FIFO RT
task over to a cpu that is running a task of lesser priority. If
migration is done, it will send a reschedule request to the found
cpu by IPI interrupt. Once the target cpu responds the IPI
interrupt, it will pick the migrated user RT task to preempt its
current task. When the user RT task is running on the new cpu,
the sched timer tick of the cpu fires. So it will tick the user
RT task again. This also means the RT task timeout value will be
updated again. As the migration may be done in one tick period,
it means the user RT task timeout value will be updated twice
within one tick.

If we set a limit on the amount of cpu time for the user RT task
by setrlimit(RLIMIT_RTTIME), the SIGXCPU signal should be posted
upon reaching the soft limit.

But exactly when the SIGXCPU signal should be sent depends on the
RT task timeout value. In fact the timeout mechanism of sending
the SIGXCPU signal assumes the RT task timeout is increased once
every tick.

However, currently the timeout value may be added twice per
tick. So it results in the SIGXCPU signal being sent earlier
than expected.

To solve this issue, we prevent the timeout value from increasing
twice within one tick time by remembering the jiffies value of
last updating the timeout. As long as the RT task's jiffies is
different with the global jiffies value, we allow its timeout to
be updated.

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Fan Du <fan.du@windriver.com>
Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1342508623-2887-1-git-send-email-ying.xue@windriver.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ lizf: backported to 3.4: adjust context ]
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
fix false disconnect due to a signal sent to the reading process

- In the current implementation, when a signal is sent to the reading process,
  read is cancelled by calling usb_ep_dequeue, which lead into calling
  acc_complete_out with ECONNRESET, but the current logic treats it as
  disconnection, which makes the device inaccessible until cable is actually
  disconnected.
- The fix calls disconnect only when ESHUTDOWN error is passed.
- If data has already arrived while trying cancelling, the data is marked
  as available, and it will be read out on the next read. This is necessary
  as USB bulk is assumed to guarantee no data loss.

Signed-off-by: keunyoung <keunyoung@google.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: kgsl: Don't block on detach if the context is invalid

An invalidated context means that something pretty nasty happened and
likely there was an unrecovered GPU fault along the way. If this is
the case then the GPU is likely not processing commands for the context
anymore. Don't block for the last retired global if the context was
invalidated.

Change-Id: Ic0dedbad22a22b704baf14557d7e18cc4cf1044a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: kgsl: Refcount mmu clock calls and allow multiple disable events

Allow each mmu clock enable call to enable the clock and let the
clock driver refcounting mechanism deal with switching the clock
off at the right time. This also means that each enable call should
have a disable call or a disable event registered, so allow for
multiple disable events to be registered. This simplifies the mmu
clock handling mechanism which is better for multiple ringbuffer
implementation. With multiple ringbuffers each global timestamp is
tied to a specific ringbuffer and with a single clock disable event
it is hard to figure out when the clock should be turned off.

CRs-fixed: 597193 592485
Change-Id: I924c545140bd19d95890a5fdfd0382c511abe973
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
selinux: add a ugly workaround to bail early when selinux tries to free a socket that is still in use and it ends in a Kernel panic. These lines are from opensource.samsung.com. While this will most likely put a bandaid over this Kernel panic it does not fix the bug so it might occur somewhere else if the same conditions are met but since I have only seen panics from this hook then we may as well sleep in peace.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>