deleted:    config
	deleted:    configZpower
making patching easier
patching ot 3.0.9-rc1
cleanup
patching to 3.0.11-rc1
patching to 3.0.13rc1
patching to 3.0.14-rc1
Patch to 3.0.16rc1
patching to 3.0.17-rc1
patching to 3.0.18-rc1
patching to 3.0.19-rc1
patching 3.0.20-rc1
starting to setup for -O3 compression
still updating to compile with O3
finishing -O3 buildability(is that a word?) now can compile with -O3 optimization
msm: pil-riva: allow forcing of insecure mode

Don't check wcnss firmware metadata on load, this allows us to load
wcnss firmware from Xperia T and other models.

Change-Id: I36e6b7a41fa461d0b4c510ed56dc239832cb1404
drivers/cpufreq: Add max duration for boosting

Change-Id: I87b180ecf52bf1dfe8e3bfe3be8731fea888e600
cleaning cherrypick
cpufreq: Fix sysfs deadlock with concurrent hotplug/frequency switch

Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_set_speed node eventually deadlocks with:

=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: G        W
---------------------------------------------
filemonkey/122 is trying to acquire lock:
 (s_active#13){++++.+}, at: [<c01a3d28>] sysfs_remove_dir+0x9c/0xb4

but task is already holding lock:
 (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(s_active#13);
  lock(s_active#13);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by filemonkey/122:
 #0:  (&buffer->mutex){+.+.+.}, at: [<c01a2230>] sysfs_write_file+0x28/0x140
 #1:  (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140

stack backtrace:
[<c0014fcc>] (unwind_backtrace+0x0/0x120) from [<c00ca600>] (validate_chain+0x6f8/0x1054)
[<c00ca600>] (validate_chain+0x6f8/0x1054) from [<c00cb778>] (__lock_acquire+0x81c/0x8d8)
[<c00cb778>] (__lock_acquire+0x81c/0x8d8) from [<c00cb9c0>] (lock_acquire+0x18c/0x1e8)
[<c00cb9c0>] (lock_acquire+0x18c/0x1e8) from [<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180)
[<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180) from [<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4)
[<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4) from [<c02d0e5c>] (kobject_del+0x10/0x38)
[<c02d0e5c>] (kobject_del+0x10/0x38) from [<c02d0f74>] (kobject_release+0xf0/0x194)
[<c02d0f74>] (kobject_release+0xf0/0x194) from [<c0565a98>] (cpufreq_cpu_put+0xc/0x24)
[<c0565a98>] (cpufreq_cpu_put+0xc/0x24) from [<c05683f0>] (store+0x6c/0x74)
[<c05683f0>] (store+0x6c/0x74) from [<c01a2314>] (sysfs_write_file+0x10c/0x140)
[<c01a2314>] (sysfs_write_file+0x10c/0x140) from [<c014af44>] (vfs_write+0xb0/0x128)
[<c014af44>] (vfs_write+0xb0/0x128) from [<c014b06c>] (sys_write+0x3c/0x68)
[<c014b06c>] (sys_write+0x3c/0x68) from [<c000e0e0>] (ret_fast_syscall+0x0/0x3c)

This is because store() in cpufreq.c indirectly grabs a kobject
with kobject_get() and is the last one to call kobject_put()
indirectly via cpufreq_cpu_put().

Fix this deadlock by introducing two new functions,
cpufreq_cpu_get_sysfs() and cpufreq_cpu_put_sysfs() which do the
same thing as cpufreq_cpu_{get,put}() but don't grab the kobject.

CRs-fixed: 366560
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
(cherry picked from commit f82ef51be26b44b83d86afa56b3cd9c743023470)

Change-Id: Ibde742d55fd4f770c402b8abce31ec266c57007d
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
fixing problems from cherry pick