lzo: properly check for overruns

commit 206a81c18401c0cde6e579164f752c4b147324ce upstream.

The lzo decompressor can, if given some really crazy data, possibly
overrun some variable types.  Modify the checking logic to properly
detect overruns before they happen.

Reported-by: "Don A. Bailey" <donb@securitymouse.com>
Tested-by: "Don A. Bailey" <donb@securitymouse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
block: bfq: Squashed update from BFQ-v7r4 to BFQ-v7r5

Change-Id: I749ef141246db7020cec0b10d980ec854a572603
mmc: core: enhance card removal judgement for slow removal

Function _mmc_detect_card_removed will be called to know whether
the card is still present when host->bus_ops->detect is called.
In current code, the return value of this function generally only
depend on the result of sending cmd13 to card, which may not safe
for card with detection support like slot gpio detection.
Because the communication status between host and card may out of
sync with the detect status if remove the card slowly or hands shake
during the process. The direct reason is the async between card
detect switch and card/slot pad contaction in hardware, which is
defined by spec.

The spec define card insert/remove sequence as below (both standard size
SD card and MicroSD card have the same sequence):
"Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final,
Appendix C: Card Detection Switch" (Take normally open type as example)
a)SD card insertion sequence:
  The card detection switch should be turned on after all SD card
  contact pads are connected to the host connector contact pads.
b)SD removal sequence:
  The card detection switch should be turned off when the SD card
  is just going to be removed and before any SD card contact pad is
  disconnected from the host connector contact pad.

Below is the sequence when this issue occur (Take slot gpio detection
as example and remove the card slowly during the process):
1. gpio level changed and card detect interrupt triggered.
2. mmc_rescan was launched.
3. the card pads were still contacted with the slot pads because of slow
   removal. So _mmc_detect_card_removed and mmc_rescan think card was
   still present (cmd13 succeed).
4. card pads were discontacted from the card slot pads.
So the card was actually removed finally but the card removal event
has been missed by system.
The interval length between step 1 and step 4 depends on the
card removal speed. If it's longer than the detect work schedule
delay which is 200ms, this issue will likely happen.

This patch add the card detect status check in function
_mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd
provided. If get_cd detect no card present then schedule another detect
work 200ms later.

CRs-fixed: 655754
Change-Id: I167309242c9937b023d14797177deb0e6be8838d
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Git-commit: 1450734ec61cda7bbb77afc8cb412b9d64c62d9a
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
Tested-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Philip Rakity <prakity@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
mmc: core: invoke low power mode if card is not present

If get_cd is defined and card is not present mmc_rescan
returns without invoking mmc_power_off. This would prevent
low-power modes.
Hence, invoke mmc_power_off if card is not present before
exiting mmc_rescan.

CRs-fixed: 655754
Change-Id: Id148fdf48e7f112da1251f8b60ac5d4c89a89e9f
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
block: row: Fix crash when adding a new field in bio struct

When adding new field to struct bio there is a crash in the removed
code lines. This issue was introduced by commit
80a8f0f87bee18283e9ca0a8966ec97ad9f084e5 "block: row-iosched idling
triggered by readahead pages"

(Partly) reverting this patch till root cause is fixed (on FS level).

Change-Id: Ie82bc806ea52a6370b57aa15455c85b2db10d0da
Signed-off-by: Tanya Brokhman <tlinder@codeaurora.org>
msm: cpufreq: Initialize cpufreq driver early at boot

MSM cpufreq driver registering with the CPUFreq framework during
late_initcall() may cause the device to be available a few seconds after
the clock driver is ready for changing frequency. This could be bad for
boot and/or thermal performance, since the cpu will continue to boot at
whatever frequency the bootloaders set it to.

Initialize cpufreq driver as part of device_initcalL() but only after
all the clock drivers have had a chance to initialize their devices.

Change-Id: Iaa4867108f59a368ee5b511d35ea2e8e219d39d3
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/Makefile
msm: cpufreq: Always update frequency limits when core is online

Remove condition in msm_cpufreq_init() so that when cpu is set to
online, it will call set_cpu_freq() and update the frequency limits.

CRs-Fixed: 462816
Change-Id: I40ac33c9cb4b42590a83f9d61b74f23379f5642e
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>
msm: cpufreq: Configure WQ for higer priority

When the workqueue runs at a lower priority, it gets starved by higher
priority threads. Bump the WQ priority to high to ensure cpufreq work
queue gets a fair scheduling chance

Change-Id: I9e994da94a347dceb884e72ec3dd3da468a4471d
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: Relax constraints on "msm-cpufreq" workqueue

This workqueue is not used in memory reclaim paths, so the
WQ_MEM_RECLAIM flag is not needed. Additionally, there is no
need to restrict the queue to having one in-flight work item.
Remove these constraints.

Change-Id: I9edde40917d3ec885ce061133de20680634321d0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: cpufreq: Ensure cpufreq change happens on corresponding CPU

Checking the cpus_allowed mask of the current thread before changing the
frequency doesn't guarantee that the rest of the execution will continue on
the same CPU. The only way to guarantee this is to schedule a work on the
specific CPU and also prevent hotplug  of that CPU (already done by
existing code).

Change-Id: I51a02fcc777a47d3c16f2d83c47e96f2c59f7ae6
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Revert "msm: mdp: Update sync pt. behaviour"

This reverts commit c44dde948554234c0766563029e3e64c9b91def7.
Revert "msm: mdp: Change msmfb kworker to kthread"

This reverts commit 9a619e36cbfdc60a739625580f7ecbcd28021902.

Change-Id: I28a30970b56709ffe504a7fdba1d54d2107543ed

Conflicts:
	drivers/video/msm/msm_fb.c
Revert "msm: display: command mode panel release fence"

This reverts commit 5ffcd5a84d220c6bd7672a4fe2e0e41151eb5765.

Change-Id: I5cea0ba38b927f68ca7250774fafe2e5bc797232
msm8930: display: Use Samsung's bandwidth values from kk kernel

 * Might help with underruns, especially on lt02 and melius

Change-Id: I4af1b416434ce32c2c40e2b287facabb9c9877eb

Conflicts:
	drivers/video/msm/mdp.c
	drivers/video/msm/mdp4.h
nl80211: Remove stray void nl80211_ft_event

Change-Id: I2f18051872ac77fa355411c47bfecb2426adfa40
USB: msm_otg: Fix host mode suspend bug

Capturing BSV bit before ID test msm_otg_set_vbus_state()
is leading to return suspend call without entering
USB into LPM. In host mode since there is no need for
BSV check, clear the BSV bit so that USB suspend can
go through.

This happens when a target enters host mode with no devices
attached, USB OTG will never enter LPM, as the BSV bit will
always be set.

CRs-Fixed: 493539
Change-Id: I491b7ec058e799ca4e9aa6b34c44ea1908e8dbf0
Signed-off-by: Sujeet Kumar <ksujeet@codeaurora.org>
USB: msm_otg: Fix a bug in charger detection procedure

USB PHY is put into non-driving mode and pull-down resistors on DP
and DM are disabled before starting the charger detection.  The
PHY is put into driving mode at the end of the charger detection
without enabling the pull-down resistors.  Due to this DP is
pulled high when a dedicated charger is connected.  USB controller
is not allowing PHY suspend if line state is non-zero when charger
is connected.  Enable pull-down resistors at the end of charger
detection to resolve this issue.

CRs-Fixed: 509608
Change-Id: Ic1fc663b397e29e62d526b4146e92c93c84240ac
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
wlan: prima: Sync with kk_2.7_rb1.41

 * Not much going on at CAF these days...

Change-Id: Ida0321b4aa2c7ec5bed7fda2ad935eaac150ee0f