mmc: core: enable async suspend

Enables the asynchronous suspend of card and class device.
This would enable both these devices to suspend in separate
respective threads, thus allowing other devices to suspend
concurrently.

CRs-fixed: 634333
Change-Id: Ic73022ef777b4fae4b1065f92cfa19da51a99634
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: sdhci-msm: enable async suspend

This is aimed to reduce the suspend time of sdhci-msm device.
The suspend of this device would be carried out in a separate
thread and other devices may suspend concurrently. This is
required since the mmc sub-system contributes to the major
chunk of suspend latency.

CRs-fixed: 634333
Change-Id: I7bdead2deacd96aec5201d82b143b07c470b3892
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
TTY: msm_smd_tty: Fix simultaneous open/close race condition

smd_tty_close currently has a variable that depends on a race
condition with tty_port_open. This causes a null-pointer dereference
when the same port is simultaneously being opened/closed.

Use data from a static array instead of the variable to eliminate
the race condition.

CRs-Fixed: 624398
Change-Id: Ie55d37feaadd3a15f64e18501cd3af19145dbc8e
Signed-off-by: Steven Cahail <scahail@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: smp: BUG() if smp_send_reschedule() is called for an offline cpu

Sending an IPI_RESCHEDULE to an offline CPU is incorrect and potentially
bad for both power and stability. On some sub-architectures such as MSM,
if a power-collapsed CPU is unexpectedly woken up by an IPI, it will be
begin executing without the preparations that would normally happen as
part of CPU_UP_PREPARE. If clocks, voltage regulators, or other hardware
configuration are not performed, the booting CPU may cause general
instability or (at best) poor power performance since the CPU would be
powered up but not utilized.

One common cause for such issues is misuse of add_timer_on() or APIs
such as queue_work_on() which call it. If proper precautions are not
taken to block hotplug while these APIs are called then a race may
result in IPIs being sent to CPUs that are already offline.

This same argument could be applied to other IPIs (with the exception
of IPI_WAKEUP), but the others are already restricted to only online
CPUs by existing mechanisms, so an explicit assertion is not useful.

Change-Id: I437db112e7e2fa7c0635e4e97e265692621944f1
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
usb: gadget: Fix response available notify count usage

The outstanding responses are purged and notify count is reset
during bus suspend. But the notify interrupt endpoint is not flushed.
If a request is pending with the controller, It gets finished during
resume and the notify count is decremented in the completion handler.
As the notify count is reset during the suspend its become negative now.
As the counter is not zero, interrupt notifications are queued even
though there are no responses. This is leading to watchdog bark due to
an error print messages.

Flush the notify endpoint before resetting the notify counter during
suspend. As we are modifying notify counter under spin lock, atomic
variable is not required. Ensure that notify counter never
becomes negative.

CRs-Fixed: 607029
Change-Id: I78cb7a585c1c2b527ca6b46bc99e7db8067ee21a
Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>