Squash FauxSound Control commits

Sound Control: Sound control for WCD93xx codec

Fully GPL'ed version.

Signed-off-by: faux123 <reioux@gmail.com>

Conflicts:
	sound/soc/codecs/Kconfig
	sound/soc/codecs/Makefile

Conflicts:
	sound/soc/codecs/Kconfig
	sound/soc/codecs/Makefile

Conflicts:

	sound/soc/codecs/Kconfig
	sound/soc/codecs/Makefile

Sound Control: Updated for HTC One (m7)

Signed-off-by: Paul Reioux <reioux@gmail.com>

Sound Control: Added headphone poweramp controls

bump version to 2.1 to reflec this new addition

Signed-off-by: Paul Reioux <reioux@gmail.com>

sound control: modified for Samsung Galaxy S4 (GT-9505 variants)

Signed-off-by: faux123 <reioux@gmail.com>
Add Samsung official exFat support
exfat: Upgrade to 1.2.6
frandom:  Added to build
Squash Linux 3.4.1-10

Linux 3.4.1

Linux 3.4.2

Conflicts:
	fs/ext4/mballoc.c
	fs/ext4/namei.c

Linux 3.4.3

Linux 3.4.4

Linux 3.4.5

Linux 3.4.6

Linux 3.4.7

Conflicts:
	mm/vmscan.c

Linux 3.4.8

Conflicts:
	fs/ext4/extents.c
	fs/ext4/super.c

Linux 3.4.9

Linux 3.4.10
I think this should be disabled with the OC stuff I brought in
Squash Linux 3.4.11-20

Linux 3.4.11

Linux 3.4.12

Conflicts:
	arch/arm/include/asm/mutex.h
	mm/vmscan.c

Linux 3.4.13

Linux 3.4.14

Linux 3.4.15

Linux 3.4.16

Linux 3.4.17

Linux 3.4.18

Linux 3.4.19

Linux 3.4.20
Squash Linux 3.4.21-30

Linux 3.4.21

Linux 3.4.22

Linux 3.4.23

Linux 3.4.24

Linux 3.4.25

Conflicts:
	include/linux/freezer.h

Linux 3.4.26

Linux 3.4.27

Linux 3.4.28

Linux 3.4.29

Conflicts:
	arch/arm/mm/dma-mapping.c

Linux 3.4.30
Squash Linux 3.4.31-40

Linux 3.4.31

Linux 3.4.32

Linux 3.4.33

Linux 3.4.34

Linux 3.4.35

Linux 3.4.36

Linux 3.4.37

Linux 3.4.38

Linux 3.4.39

Linux 3.4.40
Squash Linux 3.4.41-50

Linux 3.4.41

Linux 3.4.42

Conflicts:
	kernel/sched/core.c

Linux 3.4.43

Linux 3.4.44

Linux 3.4.45

Linux 3.4.46

Linux 3.4.47

Linux 3.4.48

Linux 3.4.49

Linux 3.4.50
Fix up some mis-merges from Linux merge
Squash Linux 3.4.51-60

Linux 3.4.51

Linux 3.4.52

Linux 3.4.53

Linux 3.4.54

Linux 3.4.55

Linux 3.4.56

Linux 3.4.57

Linux 3.4.58

Linux 3.4.59

Conflicts:
	kernel/futex.c

Linux 3.4.60

Conflicts:
	kernel/workqueue.c
Fix derp
Squash Linux 3.4.61-70

Linux 3.4.61

Linux 3.4.62

Linux 3.4.63

Linux 3.4.64

Linux 3.4.65

Linux 3.4.66

Linux 3.4.67

Linux 3.4.68

Linux 3.4.69

Linux 3.4.70
Squash Linux 3.4.71-80

Linux 3.4.71

Linux 3.4.72

Linux 3.4.73

Conflicts:
	block/elevator.c

Linux 3.4.74

Linux 3.4.75

Linux 3.4.76

Linux 3.4.77

Conflicts:
	arch/arm/kernel/traps.c
	drivers/net/ethernet/broadcom/tg3.c

Linux 3.4.78

Linux 3.4.79

Linux 3.4.80
Squash Linux 3.4.81-83

Linux 3.4.81

Linux 3.4.82

Linux 3.4.83

Conflicts:
	arch/arm/mm/proc-v7.S
	mm/memory_hotplug.c
	mm/vmscan.c

Conflicts:
	mm/memory_hotplug.c
Enable CPU under-clocking
Bump kernel version and re-enable stock thermal
cpufreq: Save user policy min/max instead of policy min/max during hotplug

When a CPU is hotplugged off, various fields of the policy are saved so
that they can be restored when the CPU is hotplugged back in.

The existing code saves the policy min/max field during hotplug remove and
restores it into user policy min/max during hotplug add. This results in
the loss of the user policy min/max values across a hotplug remove/add.

Fix it by saving the user policy min/max instead of policy min/max during
hotplug remove. During a hotplug add, after user policy min/max is
restored, the policy min/max is already recomputed. So, there's no risk of
going beyound any limits imposed by the CPUFREQ_ADJUST/INCOMPATIBLE
notifiers.

Change-Id: Ib8e09fa324c1f80f095c5754b5dcf2685e8e4a66
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpufreq: Fix policy getting stuck when user & kernel min/max don't overlap

Every __cpufreq_set_policy starts with checking the new policy min/max has
some overlap with the current policy min/max. This works out fine until we
end up with the policy min/max being set to a range that doesn't overlap
with the user policy min/max. Once we get into this situation, the check at
the start of __cpufreq_set_policy fails and prevents us from getting out of
this state.

This only happens when one of the CPUFREQ_ADJUST/CPUFREQ_INCOMPATIBLE
notifiers called inside __cpufreq_set_policy pick a min/max outside the
range of user policy min/max.

The real intent of the check at the start of __cpufreq_set_policy is to
make sure userspace can't set user policy min > user policy max. Since
__cpufreq_set_policy always gets called only with current user policy
min/max except when the actual user space policy min/max is changed, we can
fix the issue by simply checking the new policy min/max against current
user policy min/max.

Change-Id: Iaac805825e64d7985c41fb9052bd96baacdf3d6f
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>