REMOVING arm topology support
PORTED ALL RCU + SRCU +fix from 3.4.y Google ANDROID
PORTED ALL SMP + FIX
Small Restore for SMP after merge with 3.4.y
PORTED VFP from 3.4.y Android
Missing file for VFP and SMP fix.
PORTED tick-sched + timer_list from 3.4.y Android
More CPU Updates.
Cleaned smpboot function. for now not needed.
Updated ONLY CGROUPS + FREEZER from 3.4.y Android.
RESTORE "REMOVING arm topology support"

This reverts commit 3821e988f852c301fbc4bc065f53d5671bbc7475.
rcu: convert uses of rcu_assign_pointer(x, NULL) to RCU_INIT_POINTER

When assigning a NULL value to an RCU protected pointer, no barrier
is needed. The rcu_assign_pointer, used to handle that but will soon
change to not handle the special case.

Convert all rcu_assign_pointer of NULL value.

//smpl
@@ expression P; @@

- rcu_assign_pointer(P, NULL)
+ RCU_INIT_POINTER(P, NULL)

// </smpl>

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a9b3cd7f323b2e57593e7215362a7b02fc933e3a)

Conflicts:

	net/8021q/vlan.c
	net/netfilter/nfnetlink.c

Conflicts:

	net/ipv4/netfilter/nf_nat_amanda.c
	net/ipv4/netfilter/nf_nat_core.c
	net/ipv4/netfilter/nf_nat_ftp.c
	net/ipv4/netfilter/nf_nat_h323.c
	net/ipv4/netfilter/nf_nat_irc.c
	net/ipv4/netfilter/nf_nat_pptp.c
	net/ipv4/netfilter/nf_nat_sip.c
	net/ipv4/netfilter/nf_nat_standalone.c
	net/ipv4/netfilter/nf_nat_tftp.c
	net/netfilter/nf_conntrack_core.c

+ fix cherry-pick ...
Replace VSYNC uevent thread with a custom IOCTL.

* The uevents were causing high CPU usage in android
  system_server for really no good reason since it
  doesn't need to watch for them

Signed-off-by: mcm811 <changmin811@gmail.com>
s3cfb: Don't lock for vsync poll

Ioctl vsync polling runs in its own thread and will always hold
a lock on the framebuffer, only releasing on a vsync event, causing
microlags. Do not lock to prevent the issue from happening.

Not locking should not have any negative effect because the original
uevent code does not lock anyway.

http://review.cyanogenmod.com/#/c/23634/1
ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+

The open-coded mutex implementation for ARMv6+ cores suffers from a
severe lack of barriers, so in the uncontended case we don't actually
protect any accesses performed during the critical section.

Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
code but optimised to remove a branch instruction, as the mutex fastpath
was previously inlined. Now that this is executed out-of-line, we can
reuse the atomic access code for the locking (in fact, we use the xchg
code as this produces shorter critical sections).

This patch uses the generic xchg based implementation for mutexes on
ARMv6+, which introduces barriers to the lock/unlock operations and also
has the benefit of removing a fair amount of inline assembly code.

Cc: <stable@vger.kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reported-by: Shan Kang <kangshan0910@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit ffc1bb2031ad5bdc4b76d394de2d83c69f4afede)
+ "net: wireless: bcmdhd: Adjust PS mode if we are in 'suspend'" -> https://github.com/renaudallard/gnexus_kernel/commit/ef719a74bbc3548c71ca219959b3edfe3aeb6eef
sched: Fix OOPS when build_sched_domains() percpu allocation fails

Under extreme memory used up situations, percpu allocation
might fail. We hit it when system goes to suspend-to-ram,
causing a kworker panic:

 EIP: [<c124411a>] build_sched_domains+0x23a/0xad0
 Kernel panic - not syncing: Fatal exception
 Pid: 3026, comm: kworker/u:3
 3.0.8-137473-gf42fbef #1

 Call Trace:
  [<c18cc4f2>] panic+0x66/0x16c
  [...]
  [<c1244c37>] partition_sched_domains+0x287/0x4b0
  [<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210
  [<c123712d>] cpuset_cpu_inactive+0x1d/0x30
  [...]

With this fix applied build_sched_domains() will return -ENOMEM and
the suspend attempt fails.

Signed-off-by: he, bo <bo.he@intel.com>
Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/1335355161.5892.17.camel@hebo
[ So, we fail to deallocate a CPU because we cannot allocate RAM :-/
  I don't like that kind of sad behavior but nevertheless it should
  not crash under high memory load. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
rcu: Move PREEMPT_RCU preemption to switch_to() invocation

Currently, PREEMPT_RCU readers are enqueued upon entry to the scheduler.
This is inefficient because enqueuing is required only if there is a
context switch, and entry to the scheduler does not guarantee a context
switch.

The commit therefore moves the enqueuing to immediately precede the
call to switch_to() from the scheduler.

Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
sched: Fix KVM and ia64 boot crash due to sched_groups circular linked list assumption

If we have one cpu that failed to boot and boot cpu gave up on
waiting for it and then another cpu is being booted, kernel
might crash with following OOPS:

   BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
   IP: [<ffffffff812c3630>] __bitmap_weight+0x30/0x80
   Call Trace:
       [<ffffffff8108b9b6>] build_sched_domains+0x7b6/0xa50

The crash happens in init_sched_groups_power() that expects
sched_groups to be circular linked list. However it is not
always true, since sched_groups preallocated in __sdt_alloc are
initialized in build_sched_groups and it may exit early

        if (cpu != cpumask_first(sched_domain_span(sd)))
                return 0;

without initializing sd->groups->next field.

Fix bug by initializing next field right after sched_group was
allocated.

Also-Reported-by: Jiang Liu <liuj97@gmail.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Cc: a.p.zijlstra@chello.nl
Cc: pjt@google.com
Cc: seto.hidetoshi@jp.fujitsu.com
Link: http://lkml.kernel.org/r/1336559908-32533-1-git-send-email-imammedo@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Small Code style fix _ setting update.