msm: mdm2: Add delay between subsequent PS_HOLD for 8064 fusion3

This feature was previously added for the 8960 sglte target,
in commit 21274cf2219899ef9b46cf8b9fd8bf4ce52d057b, but it also
applies to the 8064 sglte2 target. The original commit message
follows.

During SSR first a reset of external modem is issued
and mdm_do_soft_power_on() toggles ap2mdm_soft_reset which
in turn toogles the PS_HOLD. Then a part of SSR external
modem is powered up and mdm_do_soft_power_on() again toggles
the gpio. For PMIC register stabilization we need a 1sec delay
between subsequent mdm_do_soft_power_on().
By default the delay is 500msec, so adding another 500msec for
stablization.

Signed-off-by: Joel King <joelking@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/board-8064.c

Change-Id: I8ac22d94205cb309dd5ba4b1f3a20933632298db
mmc: msm_sdcc: change the bkops_busy flag check to ignore_timeout

MMC core layer have made the "bkops_busy" flag in the mmc_command
structure absolute, use "ignore_timeout" instead.

Change-Id: I340aeb3193b43aa32034a3583e15be8261207525
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: core: remove bkops_busy flag from the mmc_command structure

As "bkops_busy" flag is no longer used, remove it from the mmc_command
structure.

Change-Id: I739030e90d37ce40a484a072e604a0e398b2872e
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: core: reduce the maximum timeout for BKOPs

Currently we have 4 mins timeout for the blocking bkops to be completed
but we have seen instances where card is surprisingly taking even more
time to complete their bkops operations. So if we let the card take
more than 4 mins then it would affect the user experience if user tries
to launch some application (or any other user operation resulting in
read from the card) while card is busy doing BKOPs.

User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.

Change-Id: I14355fb79979058f388cd726091752797c316503
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 188b2a8723b4728c7c0c4c445e1aefe6e42895c9)
mmc: core: Reduce the time to check for BKOPS need on idle

In order to allow the card to perform BKOPS as early as possible without causing degradation to a flow of requests, we reduce the time of the BKOPS delayed work to 200ms.
Based on experience, 200ms will allow requests to be performed without a delay of checking the BKOPS.
This patch also allows the host controller to set any other time if required.

Change-Id: I1e56bfd0c9471abf4da50befe6d14fe0199129e7
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 70b00220e7564b00e3b0747260fe2c2dbe62f45d)
mmc: core: disable the cache before suspend only after stopping BKOPS

mmc_cache_ctrl was called in runtime suspend before MMC interrupted BKOPS in case it is still running on the card. This caused the cache disable to timeout.
Therefore, mmc_cache_ctrl has to move to mmc_suspend where we are sure that the card can go into suspend and there is no pending activity.

CRs-Fixed: 436805
Change-Id: I76281a766f48ccacc24685a64067df4e60cfe1d8
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 67a51386fd99be62e5e68f4bc76ee00c19099cd6)
mmc: core: Cancel BKOPS checking in case MMC is suspended

If there is a race condition between the delayed BKOPS work and
the runtime suspend, and the suspend occurs before the delayed work,
the delayed work should be canceled.
Since mmc_claim_host can fail in case the host is suspended, we should
check if the delayed work is canceled before trying to claim the host.

CRs-Fixed: 443236
Change-Id: I9df506de4da6f9277a89ed608724f5b6e8585bfd
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5a3d216c005725baad96b6858dbcd370056e470c)
mmc: core: Fix a deadlock due to race between suspend and delayed BKOPS

mmc_stop_bkops calls cancel_delayed_work_sync while the host is taken.
This can cause a deadlock since the delayed work is blocked on claiming
the host. In order to prevent that, mmc_start_bkops will not
be blocked waiting on mmc_claim_host and if the host is already taken
BKOPS will not be performed.

CRs-Fixed: 446090
Change-Id: I5cda5489e254764b3231b8a12da9e3c241c969c3
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 8571386b83bea1cbadd81c75bf0614da30b6b7c0)
mmc: core: Don't cancel detect work during MMC suspend

When MMC host is suspending the cancellation of the MMC detect
work is in progress. And mmc_rescan() which had triggered for
SD card is blocked since mmcqd/1 has acquired the host lock.
The mmcqd/1 is waiting to proceed for the card status check.
Meanwhile, a write request is received on eMMC but it cannot
proceed as it is waiting for the ongoing runtime suspend to finish.
mmc: core: Fix NULL pointer dereference

mmc_signal_sdio_irq() should only be called when the function
driver registers for IRQ notification. In case, if any host
driver recieves a spurious interrupt and call mmc_signal_sdio_irq(),
ignore waking up uninitialized sdio irq thread.

CRs-Fixed: 472609
Change-Id: I831717fe80918538a18cc1f2300fe7fe2817c70f
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
BUILD: Build optimizations
CONFIG: Version v0.4
net: wireless: bcmdhd: Fix country checking
softirq: reduce latencies

In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.

This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.

This patch changes the fallback to ksoftirqd condition to :

- A time limit of 2 ms.
- need_resched() being set on current task

When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.

Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.

I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :

In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.

Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)

Before patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92

After patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
drivers: net: usb: rmnet_usb_data: Modify the autosuspend_delay_time of usb suspend to 2 second.

Avoid the modem suspend/resume frequently.

b/9911201

Change-Id: I0872f894c450b697bb2f0e05fc97c6ed0731b36a
Signed-off-by: yi-hsin_hung <yi-hsin_hung@asus.com>
(cherry picked from commit 3aceb26a7e3f96ce03bc748fa271bb32b979ae87)
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
net-fixes: flow_dissector: prevent an infinite loop (CVE-2013-4348)

Jason Wang found that a malicious packet could make skb_flow_dissect()
loop forever. We must check that IP header has a valid ihl to avoid
this loop. It involves IPIP encapsulation and ihl = 0 to trigger.

Given this bug is critical, I cooked a patch before having
a fix in upstream kernel.

Tested:

 Compiled/booted
 Ran some tests on bnx2x and explicitely disabled hardware provided rxhash
 ethtool -K eth1 rxhash off
 ethtool -K eth2 rxhash off

Google-Bug-Id: 11465355
Effort: net-fixes
Change-Id: I813e4dc48cecb05f8edfa218304e1f13fd764323
msm: msm_bus: Add NULL pointer checks.

Bus driver is crashing due to a NULL pointer
access sent by the client. A few NULL pointer
checks have been added to protect the driver
from invalid/NULL client handle.

CRs-Fixed: 458264
Change-Id: I822ad312ba1a0c0939d97eb92ea53094d408a836
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
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>
block: fiops sync preempts async

This implements CFQ like sync preempts async. But like CFQ, this
will starve async.