Update initramfs based on aries ics stage1 init

Change-Id: Id706bc043847dadf6b69a16d09063b23eb4818dc
fix mistake from previous commit.
Merge remote-tracking branch 'jt1134/ics' into ics
netfilter: adding the original quota2 from xtables-addons

The original xt_quota in the kernel is plain broken:
  - counts quota at a per CPU level
    (was written back when ubiquitous SMP was just a dream)
  - provides no way to count across IPV4/IPV6.

This patch is the original unaltered code from:
  http://sourceforge.net/projects/xtables-addons

  at commit e84391ce665cef046967f796dd91026851d6bbf3

Change-Id: I19d49858840effee9ecf6cff03c23b45a97efdeb
Signed-off-by: JP Abgrall <jpa@google.com>
netfitler: fixup the quota2, and enable.

The xt_quota2 came from
  http://sourceforge.net/projects/xtables-addons/develop

It needed tweaking for it to compile within the kernel tree.
Fixed kmalloc() and create_proc_entry() invocations within
 a non-interruptible context.
Removed useless copying of current quota back to the iptable's
struct matchinfo:
  - those are per CPU: they will change randomly based on which
    cpu gets to update the value.
  - they prevent matching a rule: e.g.
      -A chain -m quota2 --name q1 --quota 123
     can't be followed by
      -D chain -m quota2 --name q1 --quota 123
    as the 123 will be compared to the struct matchinfo's quota member.

Change-Id: I021d3b743db3b22158cc49acb5c94d905b501492
Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: quota2: add support to log quota limit reached.

This uses the NETLINK NETLINK_NFLOG family to log a single message
when the quota limit is reached.
It uses the same packet type as ipt_ULOG, but
 - never copies skb data,
 - uses 112 as the event number (ULOG's +1)

It doesn't log if the module param "event_num" is 0.

Change-Id: I6f31736b568bb31a4ff0b9ac2ee58380e6b675ca
Signed-off-by: JP Abgrall <jpa@google.com>
Enable quota2 and mangle support needed by netd

I enabled with menuconfig, so it also sorted out some other Kconfig
stuff.

Change-Id: Ib828611f98ec4f743abe378fd19b67a0a7177ddc
defconfig: additional crypto for device encryption and vpn
Modified PX_PROTO_* defines to match those of android
ksm: annotate ksm_thread_mutex is no deadlock source

commit 62b61f611e ("ksm: memory hotremove migration only") caused the
following new lockdep warning.

  =======================================================
  [ INFO: possible circular locking dependency detected ]
  -------------------------------------------------------
  bash/1621 is trying to acquire lock:
   ((memory_chain).rwsem){.+.+.+}, at: [<ffffffff81079339>]
  __blocking_notifier_call_chain+0x69/0xc0

  but task is already holding lock:
   (ksm_thread_mutex){+.+.+.}, at: [<ffffffff8113a3aa>]
  ksm_memory_callback+0x3a/0xc0

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (ksm_thread_mutex){+.+.+.}:
       [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
       [<ffffffff81505d74>] __mutex_lock_common+0x44/0x3f0
       [<ffffffff81506228>] mutex_lock_nested+0x48/0x60
       [<ffffffff8113a3aa>] ksm_memory_callback+0x3a/0xc0
       [<ffffffff8150c21c>] notifier_call_chain+0x8c/0xe0
       [<ffffffff8107934e>] __blocking_notifier_call_chain+0x7e/0xc0
       [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff813afbfb>] memory_notify+0x1b/0x20
       [<ffffffff81141b7c>] remove_memory+0x1cc/0x5f0
       [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
       [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
       [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
       [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
       [<ffffffff8114f398>] vfs_write+0xc8/0x190
       [<ffffffff8114fc14>] sys_write+0x54/0x90
       [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b

  -> #0 ((memory_chain).rwsem){.+.+.+}:
       [<ffffffff8108b5ba>] __lock_acquire+0x155a/0x1600
       [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
       [<ffffffff81506601>] down_read+0x51/0xa0
       [<ffffffff81079339>] __blocking_notifier_call_chain+0x69/0xc0
       [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff813afbfb>] memory_notify+0x1b/0x20
       [<ffffffff81141f1e>] remove_memory+0x56e/0x5f0
       [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
       [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
       [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
       [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
       [<ffffffff8114f398>] vfs_write+0xc8/0x190
       [<ffffffff8114fc14>] sys_write+0x54/0x90
       [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b

But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.

Thus, This patch annotate ksm_thread_mutex is not deadlock source.

[akpm@linux-foundation.org: update comment, from Hugh]
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm: drain pagevecs to lru

It was hard to explain the page counts which were causing new LTP tests
of KSM to fail: we need to drain the per-cpu pagevecs to LRU occasionally.

Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: CAI Qian <caiqian@redhat.com>
Cc:Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm: fix NULL pointer dereference in scan_get_next_rmap_item()

Andrea Righi reported a case where an exiting task can race against
ksmd::scan_get_next_rmap_item (http://lkml.org/lkml/2011/6/1/742) easily
triggering a NULL pointer dereference in ksmd.

ksm_scan.mm_slot == &ksm_mm_head with only one registered mm

CPU 1 (__ksm_exit)		CPU 2 (scan_get_next_rmap_item)
 				list_empty() is false
lock				slot == &ksm_mm_head
list_del(slot->mm_list)
(list now empty)
unlock
				lock
				slot = list_entry(slot->mm_list.next)
				(list is empty, so slot is still ksm_mm_head)
				unlock
				slot->mm == NULL ... Oops

Close this race by revalidating that the new slot is not simply the list
head again.

Andrea's test case:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>

#define BUFSIZE getpagesize()

int main(int argc, char **argv)
{
	void *ptr;

	if (posix_memalign(&ptr, getpagesize(), BUFSIZE) < 0) {
		perror("posix_memalign");
		exit(1);
	}
	if (madvise(ptr, BUFSIZE, MADV_MERGEABLE) < 0) {
		perror("madvise");
		exit(1);
	}
	*(char *)NULL = 0;

	return 0;
}

Reported-by: Andrea Righi <andrea@betterlinux.com>
Tested-by: Andrea Righi <andrea@betterlinux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
wm8994: add ring states that match userland audio libraries
initramfs: fix lpm mode
Add bootmode injection support

I tried to cherry-pick the following two commits from the aries kernel:

aries: Add bootmode injection support
10fd786bd425a310b63eb6be4bb8ccf9f7c92f39

aries: Only inject bootmode if bootmode is single digit
43a10baf0aeec07bfc1913b76a29b2a20d0f9c7a

But the changes were too different.
This commit is the manual port of this change.

Change-Id: I498083b591e5ca961203f3a182226f0b679ac866
pn544: Perform reset to correctly trigger firmware download mode.

The pn544 data sheet is not clear that a full reset with GPIO4 held high is
required to trigger firmware download mode. This fixes as per actual behavior.

Also, increase max buffer size to 512 in order to support firmware download.

Also, increase GPIO delays from 3/7ms (as per data sheet) to 10ms. NXP
engineers insist that 10ms is much more safe.

Change-Id: Ib3f2ad373d6e3768ac26b5532c925d6913fb5ea7
Signed-off-by: Nick Pelly <npelly@google.com>
pn544: Increase GPIO toggle delays again as per experimental results

We've already been running with these new delays for a while, just moving
from userspace to kernel.
ARM: S5PC11X: improve USB signal quality

Tunning of PHY0 Tune Register to improve physical characteristics.
This improves the margin of USB eye diagram, which means
the quality of USB signal is also improved.

Signed-off-by: Thomas Ryu <smilesr.ryu@samsung.com>
misc: fsa9480: make interrupt handling more robust

- fsa9480 interrupt is actually triggered low, not falling
- process any queued events and only handle the last

Change-Id: Id7b99068b226346a609454f41d75f10a86259898
Signed-off-by: Simon Wilson <simonwilson@google.com>
Wave good by to build.sh :)

Change-Id: I020fb5cf3ac7ff9e9e081bc850beb0b8b2ff2552