ipv4: route: update to the new work name.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Revert "Revert "mako: msm: board: enable HS200 bus speed mode support""

This reverts commit e039dcb2ebcf3afcfc133caefb60a6836f437a63.
msm: camera: nullify pointers after kfree and fix the memory leaks

nullify pointers after kfree and remove unnecessary kmallocs

Also fix the memory leaks. should free the memory after v4l2_event_dequeue()
even if there are some errors in copy_to/from_user(). Because entry was
already removed from its own list after v4l2_event_dequeue().

Change-Id: I733538c2fd76a6b77cfd8d6b780caebcb3fd70a8
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
v4l2: fix the memory leak

commit 9985432a82e6700cf9759f413ecaecbf617318cb

check for fh->dev being NULL before kzalloc to fix the memory leak

Change-Id: I3377ef39297f63c692aa5451d2bdbe327e2df18a
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: fix race conditions in runtime PM

commit 386ad800716b6660d40c677b57ee4bf8e4430329 msm-3.4

What is the race condition? (NOTE: RPM stands for Runtime Power Management)

1. SDCC is in RPM_SUSPENEDED state and SDCC platform suspend gets
   triggered and then system goes into suspend.
2. During platform resume, SDCC platform resume is triggered
   which blindly sets the pending_resume flag in SDCC host structure.
3. If new MMC transfer request comes then MMC block driver calls
   mmc_claim_host() which internally calls msmsdcc_enable().
4. msmsdcc_enable() checks for following 3 conditions to be true:
	1. host->sdcc_suspended == true
	2. host->pending_resume == true
	3. pm_runtime_suspended() == false
   But as SDCC state is RPM_SUSPENDED, 3rd condition is not be satisfied
   so msmsdcc_enable() don't clear the host->pending_resume flag and simply
   calls pm_runtime_get_sync() to resume the SDCC. Once SDCC is resumed,
   host->sdcc_suspended = false, runtime_status = RPM_ACTIVE but
   host->pending_resume is still set.
5. Now after RPM idle timeout, SDCC runtime suspend gets triggered which
   calls SDCC driver's runtime suspend callback (msmsdcc_runtime_suspend).
   Note that before executing the RPM suspend calllback, SDCC RPM status
   is set to RPM_SUSPENDING.
6. As SDCC driver's runtime suspend callback gets executed, it sets the
   host->sdcc_suspended to true. But now before the RPM framework
   sets the SDCC RPM status to RPM_SUSPENDED, on other active CPU core,
   new MMC transfer reques comes in which would first call msmsdcc_enable()
   and all of the 3 conditions below is true:
	1. host->sdcc_suspended == true
	2. host->pending_resume == true
	3. pm_runtime_suspended() == false (RPM status is RPM_SUSPENDING)

   As these conditions are satisfied, msmsdcc_enable() does not call
   pm_runtime_get_sync(), instead just calls pm_runtime_get_noresume() and
   msmsdcc_runtime_resume(). This means even after execution of
   msmsdcc_enable(), SDCC RPM status is either RPM_SUSPENDING or
   RPM_SUSPENDED.
7. RPM suspend framework on 1st core sets the SDCC RPM status to
   RPM_SUSPENDED once SDCC runtime suspend callback returns.
8. Now once MMC transfer request is completed on other core, it will call
   msmsdcc_disable(). This function calls pm_runtime_put_sync() which
   returns -EAGAIN error as RPM status is already RPM_SUSPENED.
   This error gets returned to MMC layer so MMC layer thinks that
   SDCC is still enabled and skips call to msmsdcc_enable() until
   msmsdcc_disable() succeeds.
8. Note when msmsdcc_disable() returned error, RPM usage_counter was set to
   0 so next call to msmsdcc_disable() decrements RPM usage_counter to -1
   (remember msmsdcc_enable() was skipped).
9. Now new MMC request comes in and it will first call msmsdcc_enable()
   which calls pm_runtime_get_sync() and it sets the usage_counter to 0
   and blindly resumes the SDCC as it was already suspended. After this
   RPM status will be RPM_ACTIVE.
10. Once MMC request is processed, it will call smsdcc_disable() which
    calls pm_runtime_put_sync() and it decrements RPM usage counter to -1
    and skips scheduling runtime suspend callback as RPM usage counter
    is not 0. RPM status remains in RPM_ACTIVE.
11. Now onwards for every new MMC transfer requests, 9 and 10 repeats and
    SDCC always stays in RPM_ACTIVE state forever.

How is this race condition fixed?

Above race is created because host->pending_resume is remaining sticky.
Following changes are done to ensure that pending_resume gets set and
cleared at appropriate places:
1. In SDCC platform resume callback, set the host->pending_resume flag
   only if RPM status is RPM_ACTIVE.
2. Clear the pending_resume flag once msmsdcc_runtime_resume() is
   completed.
3. In msmsdcc_enable() function, if pending_resume flag is set skip calling
   pm_runtime_get_sync() instead directly call msmsdcc_runtime_resume()
   because RPM status is RPM_ACTIVE.

In addition, this patch adds WARN() messages in case of failures in
msmsdcc_enable() and msmsdcc_disable() functions to capture more details
in error conditions.

CRs-Fixed: 373338
Change-Id: I50d1bd63480c668dd2b83f01567f912661f0c606
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active

worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
isn't zero when every worker is idle.  This can trigger spuriously
while a cpu is going down due to the way trustee sets %WORKER_ROGUE
and zaps nr_running.

It first sets %WORKER_ROGUE on all workers without updating
nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and
then zaps nr_running.  If the last running worker enters idle
inbetween, it would see stale nr_running which hasn't been zapped yet
and trigger the WARN_ON_ONCE().

Fix it by performing the sanity check iff the trustee is idle.

Change-Id: I78c6300647a9e14a5f5f27fee0679d9072481188
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
nohz: Fix idle ticks in cpu summary line of /proc/stat

Git commit 09a1d34f8535ecf9 "nohz: Make idle/iowait counter update
conditional" introduced a bug in regard to cpu hotplug. The effect is
that the number of idle ticks in the cpu summary line in /proc/stat is
still counting ticks for offline cpus.

Reproduction is easy, just start a workload that keeps all cpus busy,
switch off one or more cpus and then watch the idle field in top.
On a dual-core with one cpu 100% busy and one offline cpu you will get
something like this:

%Cpu(s): 48.7 us,  1.3 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi,  0.0 si,
%0.0 st

The problem is that an offline cpu still has ts->idle_active == 1.
To fix this we should make sure that the cpu is online when calling
get_cpu_idle_time_us and get_cpu_iowait_time_us.

[Srivatsa: Rebased to current mainline]

Change-Id: I53cd02fef784647e45abb4c99ff641e5e69a9d3e
Reported-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20121010061820.8999.57245.stgit@srivatsabhat.in.ibm.com
Cc: deepthi@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
timers: Fix endless looping between cascade() and internal_add_timer()

Adding two (or more) timers with large values for "expires" (they have
to reside within tv5 in the same list) leads to endless looping
between cascade() and internal_add_timer() in case CONFIG_BASE_SMALL
is one and jiffies are crossing the value 1 << 18. The bug was
introduced between 2.6.11 and 2.6.12 (and survived for quite some
time).

This patch ensures that when cascade() is called timers within tv5 are
not added endlessly to their own list again, instead they are added to
the next lower tv level tv4 (as expected).

Change-Id: Ia4e9b79767a4d255f676ecbb739b537bbe7033af
Signed-off-by: Christian Hildner <christian.hildner@siemens.com>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: http://lkml.kernel.org/r/98673C87CB31274881CFFE0B65ECC87B0F5FC1963E@DEFTHW99EA4MSX.ww902.siemens.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm_fb: display: Enable scaling bit while setting x-flip bit

To enable left-right flip x-scaling bit should be set for
MDP 4.2 and above versions. This fixes the issue when RGB layer
pipes are not properly rotated.

Change-Id: I0afae4aecde39ce3ac4dcbefc0bda93510e7d18a
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako: Adjust .drv value to 10mA

Fixes ULP timeout issues that causes USB enumeration failures.

b/7438555

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
vfs: dcache: fix deadlock in tree traversal

IBM reported a deadlock in select_parent().  This was found to be caused
by taking rename_lock when already locked when restarting the tree
traversal.

There are two cases when the traversal needs to be restarted:

 1) concurrent d_move(); this can only happen when not already locked,
    since taking rename_lock protects against concurrent d_move().

 2) racing with final d_put() on child just at the moment of ascending
    to parent; rename_lock doesn't protect against this rare race, so it
    can happen when already locked.

Because of case 2, we need to be able to handle restarting the traversal
when rename_lock is already held.  This patch fixes all three callers of
try_to_ascend().

IBM reported that the deadlock is gone with this patch.

[ I rewrote the patch to be smaller and just do the "goto again" if the
  lock was already held, but credit goes to Miklos for the real work.
   - Linus ]

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: set IO_PAD_PWR_SWITCH bit based on IO voltage level

SDCC4 controller has IO_PAD_PWR_SWITCH control bit in MCI_CLK register.
Driver should set this bit to 1 if the IO voltage level is within
low voltage range (1.7v - 1.9v) else clear it.

But driver sets this bit to 1 only if the MMC core layer initiates
the voltage switch sequence. So if voltage switch sequence is not
initiated (which is the case with non UHS-I cards) then even if
the IO voltage level is within low voltage range, IO_PAD_PWR_SWITCH
bit remains cleared.

This change checks the IO voltage level and based on that sets the
IO_PAD_PWR_SWITCH bit.

CRs-Fixed: 386445
Change-Id: Id0648b0f87ea9bcc942e855e30da810e0fe5ebf5
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: add support for AUTO_CMD19 control

SDR104 (supported by SD3.0 spec compliant SD cards) bus speed mode
requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz. To help the sampling clock
tuning SD3.0 specification has added CMD19.

During card initialization, driver uses these tuning commands to search
for optimal sampling point and then programs the DLL HW with this optimal
sampling point.

In addition, our SDCC controller's DLL HW has a mechansim of data
tracking (CDR) which can be enabled during read transaction so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern commands (CMD19) can be sent
automatically by HW (by using AUTO_CMD19 bit) before any RX transaction
for helping the CDR to track after the correct sampling point.

Although sending CMD19 automatically before every read commands is
overhead and reduces read performance by ~1 MB/s. SD spec does
not mandate to send these commands before every read operations.

This change keeps AUTO_CMD19 disabled by default but provides sysfs
attribute to enable or disable AUTO_CMD19 as per need.

Change-Id: I9ef99a8dde9b9733ea99639cdab2b6714ac50d76
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: correct the hardware version number

SDCC core version number in MSM8974 is 0x2b and not 0x2d. Fixing this
and enabling hard reset supported in this newer sdcc core.

Change-Id: Ib216330af59f854ca7ebc8735b624f3005e1ba39
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: add support for AUTO_CMD21

Using HS200 (supported by eMMC 4.5 spec compliant cards) bus speed
mode requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz so that both host and card
are in sync. eMMC 4.5 spec has added CMD21 for this tuning mechanism.

During card initialization, driver uses the tuning command to search
for an optimal sampling point and then programs the DLL HW with this
optimal sampling point.

In addition, msm SDCC controller's DLL HW has a mechansim for data
tracking (CDR) which can be enabled during read transactions so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern command (CMD21) can be sent
automatically by HW (by using AUTO_CMD21 bit) before any RX transaction
to help CDR keep track of the correct sampling point.

Since sending CMD21 automatically before every read commands is an
overhead, reducing read performance by ~1 MB/s and eMMC spec does not
mandate sending the tuning command before every read operation, this
change adds support for AUTO_CMD21 (and keeps it disabled by default)
while providing a sysfs attribute to enable or disable AUTO_CMD21 as
needed.

Change-Id: I6e053db8878b273a407fa7caf8332eb064f351ce
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: Print data line status in case of errors

The MCI_TEST_INPUT register of the SDC controller depicts the status
of the data lines (if pulled down or not). Print its state in cases of
errors to isolate any device specific issues.

CRs-Fixed: 392889
Change-Id: I5d0dbcf3fb606e6a31ede58d7cc6b27f3fb80af7
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: data timeout errors are expected during HS200 tuning

HS200 bus speed mode requires DLL (Delay locked loop) HW block to be
tuned as clock rate (192 MHz) is greater than 100MHz.

While tuning the DLL block by sending CMD21 for different DLL phases,
it is quite possible that few CMD21 may fail with data CRC/timeout
errors as clock phase is not correct but these errors are not really
worth to be printed out as kernel messages. This change doesn't allow
these errors to be printed.

CRs-Fixed: 401743
Change-Id: I2b465a8e1d52458e8663d48791083be7fa4131b2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: set DDR timing mode before setting the clock rate

Setting DDR timing mode in controller before setting the clock
rate will make sure that card don't see the double clock rate
even for very small amount duration. Some eMMC cards seems to lock
up if they see clock frequency > 52MHz.

Change-Id: I8105cf52c07df01d66c3e15304ea10e2cbc498ff
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: msm_sdcc: Reset SPS BAM on error recovery

In the current soft reset sequence performed as part of
CMD/DATA error recovery we do the following:
1) Write 1 to DML_SW_RESET
2) Reset CPSM/DPSM by clearing MCI_CMD and MCI_DATA_CTL
or by writing to MCI_SW_RST_CONFIG.
3) Re-init DML
4) Reconfigure both consumer and producer BAM pipes.

The BAM pipe reset does not reset the sideband signals, since
only SDCC side is reset SDCC - BAM communication will go out
of sync and cause DML to be stuck without transferring data.
Hence reset BAM core every time SDCC is reset (which is on
error recovery).

Fix error handling for sps pipe or device reset.

Change-Id: I745e015c862fffa36a814cd007d2e82383668b3a
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
slub: fix a possible memory leak

Memory allocated by kstrdup should be freed,
when kmalloc(kmem_size, GFP_KERNEL) is failed.

Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>