first commit
fs/cifs/transport.c: initialize variables
 drivers/hwmon/epm_adc.c: initialize variables
drivers/media/common/tuners/xc4000.c: initialize variable
net/netfilter/xt_socket.c: initialize variables
fix gcc4.7 compile

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:

	arch/arm/boot/compressed/Makefile
Fix GCC 4.7 compile
Fix compile
Use AC Charging for unknown chargers
GPU OC
Linux 3.4.11

Patch from: http://www.kernel.org/pub/linux/kernel/v3.x/incr/
Added Force Fast Charge
Add BadAss Governor
Added Lionheart Governor.
oops
fix possible memory leak
Added FIOPS Scheduler.

FIOPS (Fair IOPS) ioscheduler is an IOPS based ioscheduler, so it only targets
for drives without I/O seek. It's quite similar to CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. The drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and lets the task
dispatch requests. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. I believe
CFQ isn't completely fair between tasks in such cases either.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Added Qualcomm ROW I/O Scheduler
Add support for Google Snappy compression.
Patching upstream 3.0.11->3.0.12