This is a rather minimally invasive patch to solve the problem of the
user stack growing into a memory mapped area below it. Whenever we fill
the first page of the stack segment, expand the segment down by one
page.

Now, admittedly some odd application might _want_ the stack to grow down
into the preceding memory mapping, and so we may at some point need to
make this a process tunable (some people might also want to have more
than a single page of guarding), but let's try the minimal approach
first.

Tested with trivial application that maps a single page just below the
stack, and then starts recursing. Without this, we will get a SIGSEGV
_after_ the stack has smashed the mapping. With this patch, we'll get a
nice SIGBUS just as the stack touches the page just above the mapping.

This patch fixes bus width which improves peformance for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as "8" in controller data,the SD
stack will check whether bus width is "4" and if not it will
set bus width to "1" and there by degrading peformance.

Add wakeup support to the ads7846 driver. Platforms can enable wakeup
capability by setting the wakeup flag in ads7846_platform_data. With this
patch the ads7846 driver can be used to wake the system from suspend.

Previous ocr_mask ranges the support voltage only 1v6~1v95.
This caused an error of "host doesn't support this operating voltage"
in the initial communication between host and card.
It's fixed by providing appropriate ocm_mask.

Since MMC2 internal clock enable is requested to have regulator.
In some cases, such as beagleboard doesn't have support of
regulator (vmmc2). Therefore, moving internal clock enabling
from set_power to mmc_init makes more sense.

Now that we're murder-synchronous, this code path will never be
called (and if it does, it doesn't tell us anything useful other
than we killed a task that was already being killed by somebody
else but hadn't gotten its' signal yet)

binder_deferred_release was not unmapping the page from the buffer
before freeing it, causing memory corruption. This only happened
when page(s) had not been freed by binder_update_page_range, which
properly unmaps the pages.

This only happens on architectures with VIPT aliasing.

To reproduce, create a program which opens, mmaps, munmaps, then closes
the binder very quickly. This should leave a page allocated when the
binder is released. When binder_deferrred_release is called on the
close, the page will remain mapped to the address in the linear
proc->buffer. Later, we may map the same physical page to a different
virtual address that has different coloring, and this may cause
aliasing to occur.

PAGE_POISONING will greatly increase your chances of noticing any
problems.

Disable hardware watchgod in the cpu suspend code, right before wfi
instead of driver suspend hooks. This allows us to catch any lockups in
the suspend / resume path that are caused by driver suspend / resume hooks.

Hard lockups turn into reboot in production, so users do not have to pull
their battery.

This patch optimizes lowmemkiller to not do any work when it has an outstanding
kill-request. This greatly reduces the pressure on the task_list lock
(improving interactivity), as well as improving the vmscan performance
when under heavy memory pressure (by up to 20x in tests).

We can't be holding the mmap_sem while calling flush_cache_user_range
because the flush can fault. If we fault on a user address, the
page fault handler will try to take mmap_sem again. Since both places
acquire the read lock, most of the time it succeeds. However, if another
thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
between the call to flush_cache_user_range and the fault, the down_read
in do_page_fault will deadlock.

Also, since we really can't be holding the mmap_sem while calling
flush_cache_user_range AND vma is actually unused by the flush itself,
get rid of vma as an argument.

As part of formating the mass storage device, Host sends the INQUIRY
scsi command. As per the standard, the command length for this
command should be 6 bytes, whereas the Vista host sends 12 bytes.

When the command length of the command is not equal to the standard
length, the device sends a phase error as part of the status phase.
When the host receives a phase error, it re-enumerates, hence the
error.

If the command is INQUIRY, and the command length is 12 bytes,
treating this as a good command and not sending the phase error
to the host fixes this issue.

Under certain circumstances, a process can take awhile to
handle a sig-kill (especially if it's in a scheduler group with
a very low share ratio). When this occurs, lowmemkiller returns
to vmscan indicating the process memory has been freed - even
though the process is still waiting to die. Since the memory
hasn't actually freed, lowmemkiller is called again shortly after,
and picks the same process to die; regardless of the fact that
it has already been 'scheduled' to die and the memory has already
been reported to vmscan as having been freed.

Solution is to check fatal_signal_pending() on the selected
task, and if it's already pending destruction return; indicating
to vmscan that no resources were freed on this pass.