usb:gadget:android: avoid sending extra uevents

Don't schedule a uevet from android_disconnect
if there is no change in the connection state
and if the DISCONNECT event was already sent.
This patch will avoid these unecessary messages:

android_work: did not send uevent (0 0   (null))

Change-Id: Ic25e09f24098dcc575f4a24fdb0a0ec49ad0f430
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Linux 3.0.30
colorcontrol: fix compiler warning
twl-rtc: mask alarm interrupts at shutdown.

Mask alarm interrupts when the system is shutdown so that we don't
get powered up unnecessarily.

Change-Id: I732577f1d62a28e880c193a3d7d7d6bcdaf863d2
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>
arm: vfp: Fix memory corruption on PM suspend

Commit 36af2a47 ("ARM: vfp: Always save VFP state in vfp_pm_suspend")
introduced a potential use-after-free bug. On SMP systems,
vfp_current_hw_state might hold dangling pointers in case a task which
used the VFP last migrates to another CPU and then exits. If
vfp_pm_suspend is called while vfp_current_hw_state still holds a
pointer to the freed thread_info, that memory location will be written,
potentially overwriting a new object allocated there.

The original problem is only relevant to UP systems in which the VFP
state is stored lazily.

Fix this by only storing the VFP state on UP systems, and avoid doing so
on SMP ones.

Change-Id: I8f7026eb735b340fcef4cf12fbd12b9a0ea08d3f
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Colin Cross <ccross@android.com>
ARM: vfp: only clear vfp state for current cpu in vfp_pm_suspend

vfp_pm_suspend runs on each cpu, only clear the hardware state
pointer for the current cpu.  Prevents a possible crash if one
cpu clears the hw state pointer when another cpu has already
checked if it is valid.

Change-Id: I997ab1554944eba86730818ff242d7ebe1b32736
Signed-off-by: Colin Cross <ccross@android.com>
tempcontrol: always show current temp in sysfs
ched: Fix select_fallback_rq() vs cpu_active/cpu_online

Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was
supposed to finally sort the cpu_active mess, instead uncovered more.

Since CPU_STARTING is ran before setting the cpu online, there's a
(small) window where the cpu has active,!online.

If during this time there's a wakeup of a task that used to reside on
that cpu select_task_rq() will use select_fallback_rq() to compute an
alternative cpu to run on since we find !online.

select_fallback_rq() however will compute the new cpu against
cpu_active, this means that it can return the same cpu it started out
with, the !online one, since that cpu is in fact marked active.

This results in us trying to scheduling a task on an offline cpu and
triggering a WARN in the IPI code.

The solution proposed by Chuansheng Liu of setting cpu_active in
set_cpu_online() is buggy, firstly not all archs actually use
set_cpu_online(), secondly, not all archs call set_cpu_online() with
IRQs disabled, this means we would introduce either the same race or
the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on
wrong CPU") -- albeit much narrower.

[ By setting online first and active later we have a window of
  online,!active, fresh and bound kthreads have task_cpu() of 0 and
  since cpu0 isn't in tsk_cpus_allowed() we end up in
  select_fallback_rq() which excludes !active, resulting in a reset
  of ->cpus_allowed and the thread running all over the place. ]

The solution is to re-work select_fallback_rq() to require active
_and_ online. This makes the active,!online case work as expected,
OTOH archs running CPU_STARTING after setting online are now
vulnerable to the issue from fd8a7de17 -- these are alpha and
blackfin.

Change-Id: I34bedb461f77bfe4af78ef5ddd3fb3a230ca3551
Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: linux-alpha@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-hubqk1i10o4dpvlm06gq7v6j@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Taras Kondratiuk <taras@ti.com>

Patch Set 1
zram: a bit more robust
net: wireless: bcmdhd: Turn OFF wlan power if interface UP fails

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
OMAP4+: HSI: Prevent HSI clock disable while ACWAKE is high

If HSI clocks are disabled while ACWAKE is high, it is possible that ACWAKE
goes low unexpectedly.
This is not seen on Link Layers which do not comply with MIPI, because in this
case ACWAKE and CAWAKE are high at the same time, so HSI clocks are not
disabled.
But for Link Layers which comply with MIPI, CAWAKE will go low independtly of
CAWAKE, and HSI driver might cut the clocks while ACWAKE is high, which causes
CAWAKE to have an unknwon value.

Change-Id: Ib37982b3702ed64a917626d1a7407d558df1b49a
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
remoteproc: use dev_dbg to print image version

The version of the remote processor's resource table format is printed
using dev_info during the startup path of a remoteproc. The version
changes very rarely and hence is converted to use a dev_dbg. An error
message is printed anyway in case of a mismatch, so this conversion is
useful in helping improve the overall processor init time.

Also, version info can be looked up using an offline readrprc utility.

Change-Id: I546d3c73582bb7a3fdb2b32b4e3df03ce3a6e7f2
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: use dev_dbg for channel creation/deletion messages

The number of rpmsg channels is decently high enough during
both the initialization and tear-up/recovery of the remote
processor to effect overall boot time. The trace level of this
print is therefore reduced to improves the overall image init
time. It also helps with the runtime performance of usecases as
they have to create and delete a channel.

Change-Id: I96c293d990bc41f1a9dcd6710ef1388fa2ce2cec
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
OMAP:MUSB:OTG: Disable MUSB DMA mode incase of DMA channel request failure

Currently in case of MUSB DMA channel request failure we are not
clearing MUSB_RXCSR_DMAENAB, MUSB_RXCSR_H_AUTOREQ and
MUSB_RXCSR_AUTOCLEAR bits of MUSB RXCSR of MUSB DMA. Which is
causing failure in receipt of data packets in next transfer.

Fix is to disable the MUSB DMA mode and related bits incase of
DMA channel request fails

Change-Id: Ie6caed6ef2a01ef647cc839c01724be32a247598
Signed-off-by: Mantesh Sarashetti <mantesh@ti.com>
colorcontrol for cm9: default is 0 instead of 60 now
colorcontrol: pre_offset sysfs for older cm9-like ROM compatibility

/sys/class/misc/samoled_color/pre_offset
cc script: toggle between old and new CM9 style colorcontrol

(not tested since I'm not on CM9 style ROMs)
buildlean.sh: changed kernel name to "leanKernel"

and keep it in defconfig
Revert "ched: Fix select_fallback_rq() vs cpu_active/cpu_online"

This reverts commit 705b3f4200555d683e7b0de24b2bad4591db45db.
leanKernel v3.5.0

- Linux 3.0.30 update
- TempControl "templimit" reflects current limit always
- ColorControl now compatible with newer CM9,
and older CM9 via "cc" toggle script ("pre_offset" sysfs)
- OMAP updates (twl-rtc, arm/vfp, hsi, musb, rpmsg)
- Android updates (usb, bcmdhd)
- zram script tweak/fix