cm 11 defconfig
AnyKernel2: really fix encryption with Unified changes
missed this in 2b20dfaac40d275d9e53ef758087143ad35ab7e8
ramdisk: Unified v2 ext4+f2fs ramdisk support
- support any possible configuration of partition formats, by detecting
the fstype and swapping in the appropriate entry
- rename to mkfstab in keeping with the new functionality
ramdisk: make f2fs fstab more sane, minor ext4 fstab change
- Add Smitty's uncommitted inline_data to f2fs
- Remove unnecessary rw's and add back nodev/nosuid and checks on f2fs for safety reasons
- Specify userdata is nonremovable for ext4
AnyKernel2: Unified v2 and fstab changes
- Unified v2 f2fs/ext4 support from
c1b776dfc3d0f360e432db67e5782c7cd2ad5796
- anykernel.sh changes for Unified v2
- updated fstabs from b54a28dc46984d6877847597439b2c39a50d1606
AnyKernel2 zip
ramdisk+AnyKernel2: fix fstab mount options, bootscript fixes
- remove faulty errors=panic option causing hung boots on f2fs
- reorder f2fs options per mount output
- remove no longer needed ext4 workaround from bootscript and add the
(now working!) options back to the fstab
- clean up no longer used LMK donotkill commands from bootscript
AnyKernel2 zip
ramdisk+AnyKernel2: suspend_trim: minor printk change to be uniform
DirtyV_defconfig
makefile : minor changes
Revert "ARM: smp: Save CPU registers before IPI_CPU_STOP processing (faux123)"

This reverts commit e61138540ffd280216821e20b7f2bdd88e5addf0.
Revert " ARM: OMAP2+: PRCM: Clear reset sources after boot"

This reverts commit c4aebbcda1ffb769b0a14dfc799dacc051eff9ad.
add 1 mb back to SuperRam config for Google camera
now 720p recording should work and not crash the camera completely
ext4: Add support for FIDTRIM, a best-effort ioctl for deep discard trim

* What
This provides an interface for issuing an FITRIM which uses the
secure discard instead of just a discard.
Only the eMMC command is "secure", and not how the FS uses it:
due to the fact that the FS might reassign a region somewhere else,
the original deleted data will not be affected by the "trim" which only
handles un-used regions.
So we'll just call it "deep discard", and note that this is a
"best effort" cleanup.

* Why
Once in a while, We want to be able to cleanup most of the unused blocks
after erasing a bunch of files.
We don't want to constantly secure-discard via a mount option.

From an eMMC spec perspective, it tells the device to really get rid of
all the data for the specified blocks and not just put them back into the
pool of free ones (unlike the normal TRIM). The eMMC spec says the
secure trim handling must make sure the data (and metadata) is not available
anymore. A simple TRIM doesn't clear the data, it just puts blocks in the
free pool.
JEDEC Standard No. 84-A441
  7.6.9 Secure Erase
  7.6.10 Secure Trim

From an FS perspective, it is acceptable to leave some data behind.
 - directory entries related to deleted files
 - databases entries related to deleted files
 - small-file data stored in inode extents
 - blocks held by the FS waiting to be re-used (mitigated by sync).
 - blocks reassigned by the FS prior to FIDTRIM.

Change-Id: I676a1404a80130d93930c84898360f2e6fb2f81e
Signed-off-by: Geremy Condra <gcondra@google.com>
Signed-off-by: JP Abgrall <jpa@google.com>

Backported to linux-3.0 by arter97
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
mmc: Disregard pending irqs in sdio

Change-Id: Iae57a9f04f5bcf5100ea532948a88e449f8f5621
Signed-off-by: Andrei F <luxneb@gmail.com>
drivers/cpufreq: update Zzmoove to v0.8

Conflicts:
	drivers/cpufreq/cpufreq_zzmoove.c
cpufreq: zzmoove v0.8 - fix settings for yank profiles
drivers/cpufreq: Zzmoove v0.9_beta1
cpufreq: Update to zzmoove 0.9-beta3

credits to ZaneZam

Conflicts:
	drivers/cpufreq/cpufreq_zzmoove.c