Pushed CPUFREQ to 3.1, implemented PLIST, updated PM QOS, fixed build...

...+ missing files from last commits
[CPUFREQ] make internal cpufreq_add_dev_* static
[CPUFREQ] unexport (un)lock_policy_rwsem* functions
[CPUFREQ] fix brace coding style issue.
[CPUFREQ] fix BUG on cpufreq policy init failure
[CPUFREQ] Remove the pm_message_t argument from driver suspend
cpufreq: Use syscore_ops for boot CPU suspend/resume (v2)
[CPUFREQ] Fix memory leak in cpufreq_stat
[CPUFREQ] remove redundant sprintf from request_module call.
[CPUFREQ] Don't set stat->last_index to -1 if the pol->cur has incorr…
cpufreq: expose a cpufreq_quick_get_max routine
PM / Core: Introduce struct syscore_ops for core subsystems PM
PM QoS: Make pm_qos settings readable
PM QOS update
PM: PM QOS update fix
Implement PLIST
Support for unconditional page sanitization

A boot command line option (sanitize_mem) is added for the page
allocator to perform sanitization of all pages upon release.

This avoids leaking sensitive information when memory is released to
the system after use, for example in cryptographic subsystems. More
specifically, the following threats are addressed:

	1. Information leaks in use-after-free or uninitialized
	variable usage scenarios, such as CVE-2005-0400,
	CVE-2009-0787 and CVE-2007-6417.

	2. Data remanence based attacks, such as Iceman/Coldboot,
	which combine cold rebooting and memory image scanning
	to extract cryptographic secrets (ex. detecting AES key
	expansion blocks, RSA key patterns, etc) or other
	confidential information.

	3. Re-allocation based information leaks, especially in the
	SLAB/SLUB allocators which use LIFO caches and might expose
	sensitive data out of context (when a caller allocates an
	object and receives a pointer to a location which was used
	previously by another user).

The "Shredding Your Garbage: Reducing Data Lifetime Through Secure
Deallocation" paper by Jim Chow et. al from the Stanford University
Department of Computer Science, explains the security implications of
insecure deallocation, and provides extensive information with figures
and applications thoroughly analyzed for this behavior [1]. More
recently
this issue came to widespread attention when the "Lest We Remember:
Cold Boot Attacks on Encryption Keys" (by Halderman et. al) paper was
published [2].

The code is largely based off the memory sanitization feature in the
PaX project (licensed under the GPL v2 terms) and the original
PG_sensitive patch which allowed fine-grained marking of pages using
a page flag.
Lowered carveout for hackfest
Call sanitize_highmem without sanitize_all_mem support

Implementing sanitize_all_mem is totally useless in an android device.
So bypass it's use and call sanitize_highmem anyways.