mmc: core: reinitalize the eMMC card always on resume

Some eMMC cards dont come out of sleep when running in HS200 mode and
so to ensure that the eMMC card is reliably brought out of sleep.

Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
(cherry picked from commit 07d1f38c55bf5c17ecfd926b92ddb167907b584e)

Change-Id: Ief71ab3324723e03cbe6bc0b66a81b7d8bc203d9
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
mmc: msm_sdcc: check for pending_resume in SDCC system suspend

If system comes out of suspend, msmsdcc_pm_resume() sets the
host->pending_resume flag if the SDCC wasn't runtime suspended.
Now if the system again goes to suspend without any SDCC activity
then host->pending_resume flag will remain set which may cause the SDCC
resume to happen first and then suspend.

To avoid this unnecessary resume/suspend, make sure that pending_resume
flag is cleared before calling the msmsdcc_runtime_suspend().

CRs-Fixed: 438081
Change-Id: I76d61b57e2af298c762af9066f0fa893071f9490
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: sdio: fix resume failure

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
be reinitialized during resume but as we are not resetting
(CMD52 reset) the SDIO card during this reinitialization, card may
fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card
during resume.

CRs-Fixed: 424805
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 2679307563a616af7ab189706604a245c6a3be92)

Change-Id: Id394c2d74ef07b9e062d7a2edc5fd97abc1ea574
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>
mmc: card: abort the suspend if the card is busy

mmc_blk_suspend() is triggered when system is going into suspend which
then waits for the mmcqd thread (which processes active MMC transfer
requests) to complete all queued transfer requests but if mmcqd has
multiple requests to be processed at this point, mmc_blk_suspend() may
very well sleep for duration longer than DPM (Device Power Management)
timeout (currently 12 sec) causing the DPM timeout bug.

To fix this issue, mmc_blk_suspend() checks if there are any more pending
MMC requests in progress or not and if there are any, it returns error
which should abort the ongoing system suspend.

CRs-Fixed: 439192
Change-Id: I51a31cf43c8da4944617d1c4441a27cc6577926f
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
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.

"kworker/0:1"
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|wait_for_common(x = 0xD9391E90, ?, state = 2, iowait = 0)
-003|flush_workqueue(wq = 0xD92DCA80)
-004|mmc_suspend_host(host = 0xD8B20000)
-005|msmsdcc_runtime_suspend(dev = 0xC08B0598)
-006|pm_generic_runtime_suspend(?)
-007|__rpm_callback(cb = 0xC02F1BD8, dev = 0xC08B0598)
-008|rpm_suspend(dev = 0xC08B0598, rpmflags = 2)
-009|pm_runtime_work(work = 0xC08B065C)
-010|process_one_work(worker = 0xD9367F40, work = 0xC08B065C)
-011|worker_thread(__worker = 0xD9367F40)
-012|kthread(_create = 0xD924FF18)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

"kworker/u:4"
----
-000|need_resched()
-001|__mmc_claim_host(host = 0xD8B21000, abort = 0x0)
-002|mmc_sd_detect(host = 0xD8B21000)
-003|mmc_rescan(work = 0xD8B212A0)
-004|process_one_work(worker = 0xCDB12440, work = 0xD8B212A0)
-005|worker_thread(__worker = 0xCDB12440)
-006|kthread(_create = 0xD8BC7F18)
-007|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/1 (running)
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|io_schedule_timeout(timeout = 2147483647)
-003|wait_for_common(x = 0xD8633E2C, ?, state = 2, iowait = 1)
-004|mmc_wait_for_req_done(host = 0xD8B21000, mrq = 0xD8633E1C)
-005|mmc_wait_for_cmd(host = 0xD8B21000, cmd = 0xD8633E50, retries = 5)
-006|get_card_status(card = 0xD8D8B800, status = 0xD8633EA4, retries = 5)
-007|mmc_blk_err_check(card = 0xD8D8B800, areq = 0xD8624440)
-008|mmc_start_req(host = 0xD8B21000, areq = 0x0, error = 0xD8633F4C)
-009|mmc_blk_issue_rw_rq(mq = 0xD8624008, ?)
-010|mmc_blk_issue_rq(mq = 0xD8624008, req = 0x0)
-011|mmc_queue_thread(d = 0xD8624008)
-012|kthread(_create = 0xD9397D80)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/0
----
-000|need_resched()
-001|rpm_resume(dev = 0xC08B0598, rpmflags = 4)
-002|__pm_runtime_resume(dev = 0xC08B0598, rpmflags = 4)
-003|msmsdcc_enable(mmc = 0xD8B20000)
-004|__mmc_claim_host(host = 0xD8B20000, abort = 0x0)
-005|mmc_blk_issue_rq(mq = 0xD8C43008, req = 0xC52C9798)
-006|mmc_queue_thread(d = 0xD8C43008)
-007|kthread(_create = 0xD9397D80)
-008|kernel_thread_exit(asm)
 ---|end of frame
    |

So remove the cancellation of the detect work for the
MMC suspend to proceed and avoid this deadlock.

CRs-Fixed: 471053
Change-Id: Id79d6b81e992b08039d639b1c0f6c2eb4a79df62
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: card: fix timeout on erase/trim command due to sanitize

Sanitize command should never be issued with timeout argument of 0,
cause then it invokes timeout.
Moreover, sanitize command should not be called from routines that
does erase/trim/secure-discard commands, but only from a routine that
issues the sanitize spesifically.(mmc_blk_issue_sanitize_rq)

Change-Id: Ia3e3737f4bad149edc2248b8a30d74a9bd812be1
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
(cherry picked from commit 9a87427db940047907aee0dc86965645656f1ca9)
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Merge 'eMMC Fixes'
FIX "block: separate out blk_rq_merge_ok() and blk_try_merge() from elevator functions"

CAF did apply following patches:

2012-02-08: "block: separate out blk_rq_merge_ok() and blk_try_merge() from elevator functions" (https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/block/elevator.c?h=msm-3.4&id=050c8ea80e3e90019d9e981c6a117ef614e882ed)

After that they applied:

2012-05-24: "block: ioctl support for sanitize in eMMC 4.5" (https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/block/elevator.c?h=msm-3.4&id=73937f5face75e05ec2a72966d04f4e20aa18379)
(this commit if faulty already after the commit from 2012-02-08!)

And then they merged:

2012-06-07: "Merge commit 'AU_LINUX_ANDROID_ICS.04.00.04.00.126' into msm-3.4" (https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/block/elevator.c?h=msm-3.4&id=f132c6cf77251e011e1dad0ec88c0b1fda16d5aa)
(this totally screwed the patch from 2012-02-08)

Now it's fixed and like it's supposed like :-)

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
drivers: usb/core: compatibility fix for CONFIG_USB_OTG

This fixes an older Qualcomm commit.

Between Linux 3.3 & 3.4 the function (do_unbind_rebind()) got changed
to (unbind_no_pm_drivers_interfaces())

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.

This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.

Between commits 8323f26ce342 ("sched: Fix race in task_group()") and
800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is
disabled"), autogroup is a wreck.

With both applied, all you have to do to crash a box is disable
autogroup during boot up, then reboot..  boom, NULL pointer dereference
due to commit 800d4d30c8f2 not allowing autogroup to move things, and
commit 8323f26ce342 making that the only way to switch runqueues:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
  Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502
  RIP: effective_load.isra.43+0x50/0x90
  Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0)
  Call Trace:
    select_task_rq_fair+0x255/0x780
    try_to_wake_up+0x156/0x2c0
    wake_up_state+0xb/0x10
    signal_wake_up+0x28/0x40
    complete_signal+0x1d6/0x250
    __send_signal+0x170/0x310
    send_signal+0x40/0x80
    do_send_sig_info+0x47/0x90
    group_send_sig_info+0x4a/0x70
    kill_pid_info+0x3a/0x60
    sys_kill+0x97/0x1a0
    ? vfs_read+0x120/0x160
    ? sys_read+0x45/0x90
    system_call_fastpath+0x16/0x1b
  Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
  RIP  [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
   RSP <ffff880221ddfbd8>
  CR2: 0000000000000000

Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Yong Zhang <yong.zhang0@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cgroup: fix exit() vs rmdir() race

commit 71b5707e119653039e6e95213f00479668c79b75 upstream.

In cgroup_exit() put_css_set_taskexit() is called without any lock,
which might lead to accessing a freed cgroup:

thread1                           thread2
---------------------------------------------
exit()
  cgroup_exit()
    put_css_set_taskexit()
      atomic_dec(cgrp->count);
                                   rmdir();
      /* not safe !! */
      check_for_release(cgrp);

rcu_read_lock() can be used to make sure the cgroup is alive.

Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[moddingg33k: backported for MSM-3.4 kernel]
Signed-off-by: moddingg33k <moddingg33k@t-online.de>
sched: Fix hotplug vs. set_cpus_allowed_ptr()

Lai found that:

  WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x2d/0x4b()
  ...
  migration_cpu_stop+0x1d/0x22

was caused by set_cpus_allowed_ptr() assuming that cpu_active_mask is
always a sub-set of cpu_online_mask.

This isn't true since 5fbd036b552f ("sched: Cleanup cpu_active madness").

So set active and online at the same time to avoid this particular
problem.

Fixes: 5fbd036b552f ("sched: Cleanup cpu_active madness")
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael wang <wangyun@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Link: http://lkml.kernel.org/r/53758B12.8060609@cn.fujitsu.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
ARM: Remove unnecessary selection of TICK_ONESHOT

In 3872c48b (tick: Document TICK_ONESHOT config option) Thomas describes
the circumstances under which TICK_ONESHOT should be selected.  This is
an internal time keeping configuration symbol which should not be
selected by platform or arch code.  So remove our select statements for
it.

This kills these warnings in OMAP builds:

kernel/time/tick-sched.c:47: warning: 'tick_do_update_jiffies64' defined but not used
kernel/time/tick-sched.c:89: warning: 'tick_init_jiffy_update' defined but not used

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
msm: rq_stats: move away from tick-sched v2

IMHO tick-sched is the wrong place for this piece of code. The only thing
which needs to be done in there is to call (void update_rq_stats()).

Let's move update_rq_stats() and wakeup_user() into 'arch/arm/mach-msm/msm_rq_stats.c'

To avoid possible conflicts and to make clear where 'update_rq_stats' belongs
to we rename it into 'msm_update_rq_stats'.

On this opportunity we also define msm-rq-stats internal declarations as static.

v2: - removed the #ifdef...#endif's in 'core.c'
    - restored the function wakeup_user() [no functional change]
    - moved 'void def_work_fn(x)' on top in 'msm_rq_stats.c'

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
Merge 'Enhanced Fixes'
kernel: alarm: :fix the BUG that device automatically powers on

The value of alarm.time is invalid if we get it by:
    memset(&alarm, 0, sizeof(alarm)).
So function of rtc_set_alarm aborts before it really calls into:
    rtc->ops->set_alarm.
Then we can`t disable the RTC alarm by that. The result is some
alarms enabled by alarm_suspend are not disabled correctly during
alarm_resume. And device will automatically power on.

CRs-fixed: 524051
Change-Id: Ibc99e62878d17ad4f50325630bf0862207e2cf3f
Signed-off-by: Figo Wang <figow@codeaurora.org>
msm: Remove incorrect SAW2 PMIC DATA commands

SAW v2.2 does not support PMIC_DLY. Remove the incorrect mapping in the
probe method. Also, PMIC_DATA0 is used by L2 SPM for enabling the S5
gang in SAW v2.2. Using this to buffer the S5 gang voltage is
unnecessary and incorrect.

Change-Id: If07b40b91f73e4ae101840f864823da968c0950b
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
msm: spm-v2: Store voltage levels into PMIC_DATA3

On certain targets, where the SPM controls the power supply for each
core, the SPM power down sequence takes care of restoring the Voltage
level after a power collapse to the appropriate sleep level. The active
voltage level is stored in the PMIC_DATA_3 register and SPM state
machine uses the data in this register to restore the voltage to the
current active level.

Change-Id: I4a25440e818abdefec8cdfd3491fe9a7d772aab4
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
usb: gadget: Do not pullup D+ by default on bootup

UDC core is starting device controllers as soon as gadget driver
is registered with the UDC, resulting in controller pulling up D+.
This can cause problems with drivers which registers with UDC during
initialization but are ready for enumeration only after user enables
it later. One example of such a driver is android.c

Change-Id: I8985839bd2659f3e3962fe85bd261cd63f43a991
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
lib: Pass the correct align offset to bitmap_find_next_zero_area_off

bitmap_find_next_zero_area_off requires everything to be given in terms
of bits. genpool no longer keeps track of everything in terms of bits
so the start address must be shifted before passing to
bitmap_find_next_zero_area_off. Without this, if the start address
is unaligned, the code will not take this into account.

Change-Id: I49e3dba51c48e2f97b03b21304e1258e83881c6b
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>