USB: gadget: diag: cleanup connect event processing

USB connect event is notified to DIAG in process context.  The
process context is achieved by scheduling a work in connect
interrupt.  But the disconnect event is notified from disconnect
interrupt context.  This is leading to synchronization problems
during fast cable connect and disconnect scenarios.

Notify the connect event from interrupt context.  Updating
product and serial number for every cable connect is redundant.
Move this to bind time and remove config work completely.

CRs-Fixed: 475955
Change-Id: I9d6685f64e0348a63dd88ea36297198ca1fd4596
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usb: gadget: u_data_hsic: Fix NULL pointer dereference

The port->in and port->out are reset to NULL during disconnect.  The
connect work checks these variables before allocating requests.  Store
port->in and port->out in local variables to free the already allocated
requests before returning.

CRs-Fixed: 488044
Change-Id: Idcdc98e4237b646934c90077a1d58990e853e344
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
ci13xxx_udc: Draw 100mA of current in unconfigured state

As a part of usb enumeration, udc driver is currently notifying the pmic
to draw 0mA of current during usb reset. The pmic driver notifies the
charger driver that usb is in suspend state if <=2mA is notified.
In 8930 targets with real battery connected, USB-CV Enumeration tests
fail after some iterations. The failure logs show an error in SOF frame
number and unexpected chirp sequence.

As a part of USB Reset, instead of notifying PMIC to draw 0mA current,
if we notify to draw 100mA current, then the USB-CV Ch-9 Enumeration
failures are not seen. It seems there is some interference when PMIC stops
charging during USB reset and causing the unexpected chirp sequence
during USB Reset.

In any case, as a part of USB reset or unconfigured state, device can draw
upto 100mA of current from USB bus. Hence notify charging driver with
100mA current draw as a part of USB reset interrupt.

CRs-Fixed: 477655
Change-Id: I2658bd570c500c62705e0c07384d6b5c900f407d
Signed-off-by: Rajkumar Raghupathy <raghup@codeaurora.org>
USB: ci13xxx_udc: Fix kernel panic during composition switch

The control endpoint requests are not nuked properly during
composition switch.  The stale request is getting completed
during enumeration of the new composition.  Kernel panics if
completion handler access already freed data.  This is happening
with RNDIS interface.

The Android composite driver dequeue the control request before
removing the composition.  The current code returns immediately
if the queue is empty.  The control endpoint queues are handled
differently.  The EP0 IN endpoint is only exposed to the composite
driver.  The controller driver takes care of queuing the request
on EP0 IN or EP0 OUT based on control transfer direction.  When
the composite driver dequeue request on control endpoint, check
both direction endpoints queues.

When USB bus is reset, nuke the control endpoints.  Flushing the
endpoint will not call completion handler.

Test endpoint queue list, request list, endpoint descriptor and
soft pull up status under spinlock to prevent any races between
dequeue and queue paths.

CRs-Fixed: 474578
Change-Id: I3d7ca4be4d6cee65707879c6c9b501f442e53018
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
ci13xxx_udc: Acquire spinlock before calling ep_nuke()

The commit b0ad433 (USB: ci13xxx_udc: Fix kernel panic during
composition switch) adds ep_nuke() function in gadget_stop_activity().

_ep_nuke() releases and re-acquires spinlock on every entry of the
function. Acquiring spinlock before calling _ep_nuke() is necessary,
else it may end up in unlocking the lock twice, as it is already
unlocked before calling _ep_nuke(), which may lead to crash.

Hence, acquire spinlocks before calling _ep_nuke() function.

CRs-Fixed: 486502
Change-Id: Ia80b9facb8e592f8fb41879dc08f9f1a04a20b48
Signed-off-by: Rajkumar Raghupathy <raghup@codeaurora.org>
USB: ci13xxx_udc:  Retire pending requests while flushing an endpoint

Rmnet and dun function drivers are designed to start fresh upon MODEM
restart.  The current code is flushing endpoints without freeing
requests.  New requests are allocated again after MODEM is powered up.
All accumulated requests are freed only upon cable disconnect.  If
MODEM is restarted multiple times without disconnecting the cable, we
are running low memory issues.

A pending request can not be freed without dequeuing it.  Dequeuing
all requests in a loop is a heavy operation and involves changing
multiple function drivers.  All pending requests are retired upon
disabling an endpoint.  But an endpoint can not be disabled in
configured state.  Hence retire pending requests while flushing an
endpoint.

CRs-Fixed: 489047
Change-Id: I3440a204ad8c4beb043b1068cb1d3965be96e9b7
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
u_ether: Handle memory allocation failure case on tx path

With multipacket feature enabled, if the memory allocation for
tx request buffer fails, accessing the req->buf leads to null pointer
dereference crash.

Hence, handle memory alloction failure case and return -ENOMEM.

CRs-Fixed: 490085
Change-Id: Ic5faac8ea7eb056755b03007c48ff085f10afa20
Signed-off-by: Rajkumar Raghupathy <raghup@codeaurora.org>
usb: chipidea: udc: fix memory access of shared memory on armv5 machines

The udc uses an shared dma memory space between hard and software. This
memory layout is described in ci13xxx_qh and ci13xxx_td which are marked
with the attribute ((packed)).

The compiler currently does not know about the alignment of the memory
layout, and will create strb and ldrb operations.

The Datasheet of the synopsys core describes, that some operations on
the mapped memory need to be atomic double word operations. I.e. the
next pointer addressing in the qhead, as otherwise the hardware will
read wrong data and totally stuck.

This is also possible while working with the current active td queue,
and preparing the td->ptr.next in software while the hardware is still
working with the current active td which is supposed to be changed:

writeb(0xde, &td->ptr.next + 0x0); /* strb */
writeb(0xad, &td->ptr.next + 0x1); /* strb */

<----- hardware reads value of td->ptr.next and get stuck!

writeb(0xbe, &td->ptr.next + 0x2); /* strb */
writeb(0xef, &td->ptr.next + 0x3); /* strb */

This appeares on armv5 machines where the hardware does not support
unaligned 32bit operations.

This patch adds the attribute ((aligned(4))) to the structures to tell
the compiler to use 32bit operations. It also adds an wmb() for the
prepared TD data before it gets enqueued into the qhead.

CRs-Fixed: 494323
Change-Id: I3fc2e0f662076572d61f97ed708026be3cd3e59c
Cc: stable <stable@vger.kernel.org> # v3.5
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: a9c174302b1590ef3ead485d804a303c5f89174b
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[pkondeti@codeaurora.org: resolved merge conflicts]
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
mfd: pm8xxx-misc: Add API to read PMIC registers

This API reads the PMIC registers at runtime and can be called
from process/interrupt context. It is currently enabled for PM8921.

Change-Id: I63a80293e37725569d075de814f27f67382976ca
Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org>
Revert "usb: force 500Ma charging current on unknown chargers"

This reverts commit 52c1c4694e889a2632ced4c657fc3a471b79e3c9.
msm: vidc: Handle mgen2maxi interrupt in video driver

Handle interrupt generated by mgen2maxi h/w and
avoid unknown interrupts storm which results in
target reset issues.

Change-Id: Ida24cb2dde15c9cd4a4c1d9ca336b1a4b662c4d1
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
msm: vidc: Get the current performance level

This change supports client to get the current
performance level of the video driver via
IOCTL_GET_PERF_LEVEL. The current performance
level indicate the number of MBs per second
is being processed by video hardware.

Change-Id: Ic6f5b2b14e0d77bf801c4f857f8a0e20339c199f
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>

Conflicts:
	drivers/video/msm/vidc/common/enc/venc.c
	include/linux/msm_vidc_enc.h
timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized
each time a CPU is brought up. If a CPU is brought online
during the period that another thread is trying to modify an
inactive timer on that CPU with holding its timer base lock,
then the lock will be reinitialized under its feet. This leads
to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466,
 .owner_cpu: 1
<4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>]
(do_raw_spin_unlock+0x40/0xcc)
<4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>]
(_raw_spin_unlock+0x8/0x30)
<4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>]
(mod_timer+0x294/0x310)
<4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>]
(queue_delayed_work_on+0x104/0x120)
<4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>]
(sdhci_msm_bus_voting+0x88/0x9c)
<4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>]
(sdhci_disable+0x40/0x48)
<4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>]
(mmc_release_host+0x4c/0xb0)
<4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>]
(mmc_sd_detect+0x90/0xfc)
<4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>]
(mmc_rescan+0x7c/0x2c4)
<4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>]
(process_one_work+0x27c/0x484)
<4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>]
(worker_thread+0x210/0x3b0)
<4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>]
(kthread+0x80/0x8c)
<4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>]
(kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU #3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU #2.
The code locked the timer_base corresponding to CPU #2. Before it could
proceed, CPU #2 came online and reinitialized the spinlock corresponding
to its base. Thus now CPU #3 held a lock which was reinitialized. When
CPU #3 finally ended up unlocking the old cpu_base corresponding to CPU #2,
we hit the above SPIN_BUG().

CPU #0			CPU #3				       CPU #2
------			-------				       -------
.....			 ......				      <Offline>
			mod_timer()
			 lock_timer_base
			  spin_lock_irqsave(&base->lock)

cpu_up(2)		 .....				        ......
							 init_timers_cpu()
.....		 	 spin_unlock_irqrestore(&base->lock)     ......
			   <spin_bug>

Allocation of per_cpu timer vector bases is done only once under
"tvec_base_done[]" check. In the current code, spinlock_initialization
of base->lock isn't under this check. When a CPU is up each time the base
lock is reinitialized. Move base spinlock initialization under the check.

CRs-Fixed: 471127
Change-Id: I73b48440fffb227a60af9180e318c851048530dd
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
hrtimer: Don't reinitialize a cpu_base's lock on CPU_UP

The current code makes the assumption that a cpu_base lock cannot
be held if a CPU is offline, which is tragically wrong.

If a hrtimer is not queued, then it will not be migrated by
migrate_hrtimers() when a CPU is offlined. Therefore, the
hrtimer's cpu_base may still point to a CPU which has
subsequently gone offline if the timer wasn't enqueued at the
time the CPU went down.

Normally this wouldn't be a problem, but a cpu_base's lock is
blindly reinitialized each time a CPU is brought up. If a CPU is
brought online during the period that another thread is
performing a hrtimer operation on a stale hrtimer, then the lock
will be reinitialized under its feet, and a SPIN_BUG() like the
following will be observed:

 [  448.212369] BUG: spinlock already unlocked on CPU#3,
 swapper/3/0
[  448.217368]  lock: 0xc47b1a40, .magic: dead4ead, .owner:
swapper/3/0, .owner_cpu: -1
[  448.217398] [<c0014398>] (unwind_backtrace+0x0/0x120) from
[<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc)
[  448.217419] [<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc) from
[<c071bbb0>] (_raw_spin_unlock_irqrestore+0xc/0x38)
[  448.217438] [<c071bbb0>]
(_raw_spin_unlock_irqrestore+0xc/0x38) from [<c00aa498>]
(hrtimer_try_to_cancel+0xf8/0x10c)
[  448.217455] [<c00aa498>] (hrtimer_try_to_cancel+0xf8/0x10c)
from [<c00aa4bc>] (hrtimer_cancel+0x10/0x20)
[  448.217475] [<c00aa4bc>] (hrtimer_cancel+0x10/0x20) from
[<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0)
[  448.217494] [<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0) from
[<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4)
[  448.217514] [<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4) from
[<c000f2dc>] (cpu_idle+0x98/0xf0)
[  448.217529] [<c000f2dc>] (cpu_idle+0x98/0xf0) from
[<000081ac>] (0x81ac)

CRs-Fixed: 460670
Change-Id: I588f6a864054abe6d4c249aad815c6d2f5a54077
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Revert "cpufreq: fix interactive bug during hotplug"

This reverts commit 940d4b98eab2577d6c1e710f2939a2b0b6b3f028.

Change-Id: I16ec442f510c45951907417a5c87cd2e31c6c645
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>
cpufreq: interactive: take idle notifications only when active

Register an idle notifier only when the governor is active.  Also
short-circuit work of idle end if the governor is not enabled.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: I4cae36dd2e7389540d337d74745ffbaa0131870f
Git-Commit: 22a51ab6e21de740c1b555f9a03626d28aaebdf3
Git-Repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>
cpufreq: interactive: reconcile with caf

Change-Id: Ibee6114368f79b263806fa9382ebfcc216ece9a8

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: keep freezer happy when not current governor

Fix a problem where the hung task mechanism was deeming the interactive
clock boost thread as hung.  This was because the thread is created at
module init but never run/woken up until needed.  If the governor is not
being used this can be forever.  To workaround this explicitly wake up
the thread once all the necessary data structures are initialized.  The
latter required some minor code shuffle.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: Ie2c058dd75dcb6460ea10e7ac997e46baf66b1fe
Git-Commit: 5ff8407798f1d8c44f3165bc535676a2a897666b
Git-Repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: handle speed up and down in the realtime task

Not useful to have a separate, non-realtime workqueue for speed down
events, avoid priority inversion for speed up events.

Change-Id: Iddcd05545245c847aa1bbe0b8790092914c813d2
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Git-Commit: f8aa05d96a0d18416d2627c493f7dc9bc5324901
Git-Repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>
cpufreq: interactive: remove input_boost handling

Now handled in userspace Power HAL instead.

Change-Id: I78a4a2fd471308bfcd785bbefcc65fede27314cf
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Git-Commit: 4e27eb56e819745a1b184f278d7f3dd3887a456c
Git-Repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c