net: wireless: bcmdhd: update bcmdhd driver to 1.15.15
delete these
Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>
bcmdhd: Revert back the wireless driver to the one in CM10 repo

Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>

Conflicts:
	drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_cdc.c
	drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_cfg80211.c
	drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c
	drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_sdio.c
	drivers/net/wireless/bcmdhd/src/wl/sys/wl_cfg80211.c
	drivers/net/wireless/bcmdhd/src/wl/sys/wl_cfgp2p.c
	drivers/net/wireless/bcmdhd/src/wl/sys/wl_iw.c
remove these

Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>
bcmdhd: update wireless driver to the one in s3 kernel

Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>

Conflicts:
	drivers/net/wireless/bcmdhd/Kconfig
	drivers/net/wireless/bcmdhd/Makefile
	drivers/net/wireless/bcmdhd/dhd_common.c
	drivers/net/wireless/bcmdhd/dhd_custom_sec.c
	drivers/net/wireless/bcmdhd/linux_osl.c
	drivers/net/wireless/bcmdhd/wl_android.c
	drivers/net/wireless/bcmdhd/wl_cfg80211.h
Just another stupid bln change.
Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>
try again with bln
Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>
ARM: 6490/1: MM: bugfix: initialize spinlock for init_mm.context

init_mm used at kernel/sched.c:idle_task_exit() has spin_lock
(init_mm.context.id_lock) that is not initialized when spin_lock/unlock
is called at an ARM machine. Note that mm_struct.context.id_lock is
usually initialized except for the instance of init_mm at
linux/arch/arm/mm/context.c

Not initializing this spinlock incurs "BUG: pinlock bad magic"
warning when spinlock debug is enabled. We have observed such
instances when testing PM in S5PC210 machines.

Change-Id: I52c6c6d035c220822a5675faaf8d163a3535985d
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Colin Cross <ccross@android.com>
sched: Improve latencies under load by decreasing minimum scheduling granularity

Mathieu reported bad latencies with make -j10 kind of kbuild
workloads - which is mostly caused by us scheduling with a
too coarse granularity.

Reduce the minimum granularity some more, to make sure we
can meet the latency target.

I got the following results (make -j10 kbuild load, average of 3
runs):

 vanilla:

  maximum latency: 38278.9 Âµs
  average latency:  7730.1 Âµs

 patched:

  maximum latency: 22702.1 Âµs
  average latency:  6684.8 Âµs

Mathieu also measured it:

|
| * wakeup-latency.c (SIGEV_THREAD) with make -j10
|
| - Mainline 2.6.35.2 kernel
|
| maximum latency: 45762.1 Âµs
| average latency: 7348.6 Âµs
|
| - With only Peter's smaller min_gran (shown below):
|
| maximum latency: 29100.6 Âµs
| average latency: 6684.1 Âµs
|

Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Suggested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <AANLkTi=8m4g01wZPacySoF7U0PevTNVgJoZZrHiUD-pN@mail.gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
update makefile
Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>
Aggressive cflags
Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>
lib/list_sort: do not pass bad pointers to cmp callback

commit f015ac3edd84ad72f88e08a4d83c56c360aae404 upstream.

If the original list is a POT in length, the first callback from line 73
will pass a==b both pointing to the original list_head.  This is dangerous
because the 'list_sort()' user can use 'container_of()' and accesses the
"containing" object, which does not necessary exist for the list head.  So
the user can access RAM which does not belong to him.  If this is a write
access, we can end up with memory corruption.

Signed-off-by: Don Mullis <don.mullis@gmail.com>
Tested-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ashmem: fix deadlock when system is low on memory

When system is low on memory, allocating memory while holding the
ashmem_mutex may try to directly reclaim memory. Then ashmem_shrink()
is called in same thread. It will deadlock at acquiring ashmem_mutex.
This change lets ashmem_shrink() return failure if ashmem_mutex is not
available. Memory will be reclaimed from others.

Change-Id: I3b6024d5477d37245f4ebde6d7069fb77af789ee
Signed-off-by: Yuanyuan Zhong <yuanyuan.zhong@gmail.com>
ashmem: Add cache flush routines to ashmem
ashmem: Fix flush routine of ashmem

The ashmem flush function ashmem_flush_cache_range was calling
dmac_clean_range and dmac_flush_range with a user virtual address
which is not allowed. Instead of calling dmac_clean_range or
dmac_flush_range use flush_cache_user_range which can be called
with a user vitual address.

Change-Id: I5dd137fb248b45ef2c7ea5f7bdb4b540b8310af9
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Makefile: Another set of new cflags, -O3

Signed-off-by: scotthartbti <scott.hart.bti@gmail.com>

Conflicts:
	Makefile
ARM: Fixes for Thumb mode. Includes:
ARM: 6191/1: Do not compile the Thumb-2 module relocations on an ARM kernel (Catalin Marinas)
ARM: Fix up vfp exception location in thumb mode (Colin Cross)
OOM rework and fixes for 2.6.35.7 (existz)
ext4: don't bump up LONG_MAX nr_to_write by a factor of 8

ext4: don't bump up LONG_MAX nr_to_write by a factor of 8

I'm uneasy with lots of stuff going on in ext4_da_writepages(),
but bumping nr_to_write from LLONG_MAX to -8 clearly isn't
making anything better, so avoid the multiplier in that case.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4: stop looping in ext4_num_dirty_pages when max_pages reached

ext4: stop looping in ext4_num_dirty_pages when max_pages reached

Today we simply break out of the inner loop when we have accumulated
max_pages; this keeps scanning forwad and doing pagevec_lookup_tag()
in the while (!done) loop, this does potentially a lot of work
with no net effect.

When we have accumulated max_pages, just clean up and return.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>