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
timer: Added usleep_range timer

usleep_range is a finer precision implementations of msleep
and is designed to be a drop-in replacement for udelay where
a precise sleep / busy-wait is unnecessary.

Since an easy interface to hrtimers could lead to an undesired
proliferation of interrupts, we provide only a "range" API,
forcing the caller to think about an acceptable tolerance on
both ends and hopefully avoiding introducing another interrupt.

INTRO

As discussed here ( http://lkml.org/lkml/2007/8/3/250 ), msleep(1) is not
precise enough for many drivers (yes, sleep precision is an unfair notion,
but consistently sleeping for ~an order of magnitude greater than requested
is worth fixing). This patch adds a usleep API so that udelay does not have
to be used. Obviously not every udelay can be replaced (those in atomic
contexts or being used for simple bitbanging come to mind), but there are
many, many examples of

mydriver_write(...)
/* Wait for hardware to latch */
udelay(100)

in various drivers where a busy-wait loop is neither beneficial nor
necessary, but msleep simply does not provide enough precision and people
are using a busy-wait loop instead.

CONCERNS FROM THE RFC

Why is udelay a problem / necessary? Most callers of udelay are in device/
driver initialization code, which is serial...

	As I see it, there is only benefit to sleeping over a delay; the
	notion of "refactoring" areas that use udelay was presented, but
	I see usleep as the refactoring. Consider i2c, if the bus is busy,
	you need to wait a bit (say 100us) before trying again, your
	current options are:

		* udelay(100)
		* msleep(1) <-- As noted above, actually as high as ~20ms
				on some platforms, so not really an option
		* Manually set up an hrtimer to try again in 100us (which
		  is what usleep does anyway...)

	People choose the udelay route because it is EASY; we need to
	provide a better easy route.

	Device / driver / boot code is *currently* serial, but every few
	months someone makes noise about parallelizing boot, and IMHO, a
	little forward-thinking now is one less thing to worry about
	if/when that ever happens

udelay's could be preempted

	Sure, but if udelay plans on looping 1000 times, and it gets
	preempted on loop 200, whenever it's scheduled again, it is
	going to do the next 800 loops.

Is the interruptible case needed?

	Probably not, but I see usleep as a very logical parallel to msleep,
	so it made sense to include the "full" API. Processors are getting
	faster (albeit not as quickly as they are becoming more parallel),
	so if someone wanted to be interruptible for a few usecs, why not
	let them? If this is a contentious point, I'm happy to remove it.

OTHER THOUGHTS

I believe there is also value in exposing the usleep_range option; it gives
the scheduler a lot more flexibility and allows the programmer to express
his intent much more clearly; it's something I would hope future driver
writers will take advantage of.

To get the results in the NUMBERS section below, I literally s/udelay/usleep
the kernel tree; I had to go in and undo the changes to the USB drivers, but
everything else booted successfully; I find that extremely telling in and
of itself -- many people are using a delay API where a sleep will suit them
just fine.

SOME ATTEMPTS AT NUMBERS

It turns out that calculating quantifiable benefit on this is challenging,
so instead I will simply present the current state of things, and I hope
this to be sufficient:

How many udelay calls are there in 2.6.35-rc5?

	udealy(ARG) >=	| COUNT
	1000		| 319
	500		| 414
	100		| 1146
	20		| 1832

I am working on Android, so that is my focus for this. The following table
is a modified usleep that simply printk's the amount of time requested to
sleep; these tests were run on a kernel with udelay >= 20 --> usleep

"boot" is power-on to lock screen
"power collapse" is when the power button is pushed and the device suspends
"resume" is when the power button is pushed and the lock screen is displayed
         (no touchscreen events or anything, just turning on the display)
"use device" is from the unlock swipe to clicking around a bit; there is no
	sd card in this phone, so fail loading music, video, camera

	ACTION		| TOTAL NUMBER OF USLEEP CALLS	| NET TIME (us)
	boot		| 22				| 1250
	power-collapse	| 9				| 1200
	resume		| 5				| 500
	use device	| 59				| 7700

The most interesting category to me is the "use device" field; 7700us of
busy-wait time that could be put towards better responsiveness, or at the
least less power usage.

Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
Cc: apw@canonical.com
Cc: corbet@lwn.net
Cc: arjan@linux.intel.com
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Fix FFC once and for all.

Requires userspace orientation of FFC to be set to 180 degrees.

Signed-off-by: Max Fierke <max@maxfierke.com>
qt602240: fix ts driver for ICS multitouch protocol

Change-Id: Ia51cbade407bb70d1895bad94c08af04562f3246
netfilter: add xt_qtaguid matching module

This module allows tracking stats at the socket level for given UIDs.
It replaces xt_owner.
If the --uid-owner is not specified, it will just count stats based on
who the skb belongs to. This will even happen on incoming skbs as it
looks into the skb via xt_socket magic to see who owns it.
If an skb is lost, it will be assigned to uid=0.

To control what sockets of what UIDs are tagged by what, one uses:
  echo t $sock_fd $accounting_tag $the_billed_uid \
     > /proc/net/xt_qtaguid/ctrl
 So whenever an skb belongs to a sock_fd, it will be accounted against
   $the_billed_uid
  and matching stats will show up under the uid with the given
   $accounting_tag.

Because the number of allocations for the stats structs is not that big:
  ~500 apps * 32 per app
we'll just do it atomic. This avoids walking lists many times, and
the fancy worker thread handling. Slabs will grow when needed later.

It use netdevice and inetaddr notifications instead of hooks in the core dev
code to track when a device comes and goes. This removes the need for
exposed iface_stat.h.

Put procfs dirs in /proc/net/xt_qtaguid/
  ctrl
  stats
  iface_stat/<iface>/...
The uid stats are obtainable in ./stats.

Change-Id: I01af4fd91c8de651668d3decb76d9bdc1e343919
Signed-off-by: JP Abgrall <jpa@google.com>
nf: qtaguid: workaround xt_socket_get_sk() returning bad SKs.

(This is a direct cherry pick from 2.6.39: Id2a9912b)

* xt_socket_get_sk() returns invalid sockets when the sk_state is TCP_TIME_WAIT.
Added detection of time-wait.
* Added more constrained usage: qtaguid insures that xt_socket_get*_sk() is
not invoked for unexpected hooks or protocols (but I have not seen those
active at the point where the returned sk is bad).

Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: Id2a9912bb451a3e59d012fc55bbbd40fbb90693f
nf: qtaguid: make procfs entry for ctrl return correct data.

(This is a direct cherry-pick from 2.6.39: I3b925802)

Fixed procreader for /proc/net/xt_qtaguid/ctrl: it would just
fill the output with the same entry.
Simplify the **start handling.

Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: I3b92580228f2b57795bb2d0d6197fc95ab6be552
netfilter: qtaguid: fix bad-arg handling when tagging socket

When processing args passed to the procfs ctrl, if the tag was
invalid it would exit without releasing the spin_lock...
Bye bye scheduling.

Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: Ic1480ae9d37bba687586094cf6d0274db9c5b28a
netfitler: xt_qtaguid: add another missing spin_unlock.

This time the symptom is caused by tagging the same socket twice
without untagging it in between.
This would cause it to not unlock, and return.

Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: qtaguid: add tag delete command, expand stats output.

* Add a new ctrl command to delete stored data.
  d <acct_tag> [<uid>]
The uid will default to the running process's.
The accounting tag can be 0, in which case all counters and socket tags
associated with the uid will be cleared.

* Simplify the ctrl command handling at the expense of duplicate code.
This should make it easier to maintain.

* /proc/net/xt_qtaguid/stats now returns more stats
  idx iface acct_tag_hex uid_tag_int
  {rx,tx}_{bytes,packets}
  {rx,tx}_{tcp,udp,other}_{bytes,packets}
the {rx,tx}_{bytes,packets} are the totals.

* re-tagging will now allow changing the uid.

Change-Id: I9594621543cefeab557caa3d68a22a3eb320466d
Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: xt_qtaguid: add uid permission checks during ctrl/stats access

* uid handling
 - Limit UID impersonation to processes with a gid in AID_NET_BW_ACCT.
   This affects socket tagging, and data removal.
 - Limit stats lookup to own uid or the process gid is in AID_NET_BW_STATS.
   This affects stats lookup.

* allow pacifying the module
  Setting passive to Y/y will make the module return immediately on
  external stimulus.
  No more stats and silent success on ctrl writes.
  Mainly used when one suspects this module of misbehaving.

Change-Id: I83990862d52a9b0922aca103a0f61375cddeb7c4
Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: qtaguid: disable #define DEBUG

This would cause log spam to the point of slowing down the system.

Change-Id: I5655f0207935004b0198f43ad0d3c9ea25466e4e
Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: xt_qtaguid: add counter sets and matching control

* Added support for sets of counters.
By default set 0 is active.
Userspace can control which set is active for a given UID by
writing to .../ctrl
   s <set_num> <uid>
Changing the active set is only permitted for processes in the
 AID_NET_BW_ACCT group.

The active set tracking is reset when the uid tag is deleted with
the .../ctrl command
  d 0 <uid>

* New output format for the proc .../stats
 - Now has cnt_set in the list.
  """
  idx iface acct_tag_hex uid_tag_int cnt_set rx_bytes rx_packets tx_bytes tx_packets rx_tcp_packets rx_tcp_bytes rx_udp_packets rx_udp_bytes rx_other_packets rx_other_bytes tx_tcp_packets tx_tcp_bytes tx_udp_packets tx_udp_bytes tx_other_packets tx_other_bytes
  ...
  2 rmnet0 0x0 1000 0 27729 29 1477 27 27501 26 228 3 0 0 1249 24 228 3 0 0
  2 rmnet0 0x0 1000 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  3 rmnet0 0x0 10005 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  3 rmnet0 0x0 10005 1 46407 57 8008 64 46407 57 0 0 0 0 8008 64 0 0 0 0
  ...
  6 rmnet0 0x7fff000100000000 10005 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  6 rmnet0 0x7fff000100000000 10005 1 27493 24 1564 22 27493 24 0 0 0 0 1564 22 0 0 0 0
  """

* Refactored for proc stats output code.
* Silenced some of the per packet debug output.
* Reworded some of the debug messages.
* Replaced all the spin_lock_irqsave/irqrestore with *_bh():
   netfilter handling is done in softirq.

Change-Id: Ibe89f9d754579fd97335617186c614b43333cfd3
Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: xt_qtaguid: recognize IPV6 interfaces. root is procfs privileged.

* Allow tracking interfaces that only have an ipv6 address.
  Deal with ipv6 notifier chains that do NETDEV_UP without the rtnl_lock()
* Allow root all access to procfs ctrl/stats.
  To disable all checks:
    echo 0 > /sys/module/xt_qtaguid/parameters/ctrl_write_gid
    echo 0 > /sys/module/xt_qtaguid/parameters/stats_readall_gid
* Add CDEBUG define to enable pr_debug output specific to
    procfs ctrl/stats access.

Change-Id: I9a469511d92fe42734daff6ea2326701312a161b
Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: xt_qtaguid: Fix socket refcounts when tagging

* Don't hold the sockets after tagging.
  sockfd_lookup() does a get() on the associated file.
  There was no matching put() so a closed socket could never be
  freed.
* Don't rely on struct member order for tag_node
  The structs that had a struct tag_node member would work with
  the *_tree_* routines only because tag_node was 1st.
* Improve debug messages
  Provide info on who the caller is. Use unsigned int for uid.
* Only process NETDEV_UP events.
* Pacifier: disable netfilter matching. Leave .../stats header.

Change-Id: Iccb8ae3cca9608210c417597287a2391010dff2c
Signed-off-by: JP Abgrall <jpa@google.com>