tf_comm.c: Fix warning: 'error' may be used uninitialized in this function
omap_hwmod_44xx_data.c: secure_timer_dev_attr define but not used
misc/bmp180.c: Fix unused variable
misc/bmp180.c: Fix raw_temperature and raw_pressure not initialized
netfilter: xt_log.h: fix warning: value computed is not used
usb: host: ehci: allow ehci_* symbols to be unused

not all platforms will use all of those ehci_*
symbols on their hc_driver structure. Sometimes
we might need to provide a modified version of
a certain method or not provide it at all, as is
the case with OMAPs which don't support port handoff
feature.

Whenever we compile a kernel for an OMAP board with
EHCI enabled, we get compile warnings:

drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \
	defined but not used
drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \
	defined but not used

In order to cleanup those warnings, we're adding
__maybe_unused annotation to those functions.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial/omap-serial.c: Fix unused variable
ARM: OMAP2+: UART: Fix compilation/sparse warnings

Fixes below compilation warning.

drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]

Fix below sparse warning.

drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in argument 2 (different signedness)
drivers/tty/serial/omap-serial.c:392:52:    expected int *status
drivers/tty/serial/omap-serial.c:392:52:    got unsigned int *<noident>

Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
Signed-off-by: Kevin Hilman <khilman@ti.com>
f_dm.c: Fix unused variablcdev + expects argument
usb: musb: gadget: use pm autosuspend in musb_gadget_pullup

If musb_gadget_pullup doesn't use pm autosuspend, next may happen:

time |   pseudocode
------------------------------------------------------------
t1   | pm_runtime_put_autosuspend() scedules suspend at 't4'
     |     /* some code running */
t2   | musb_gadget_pullup: pm_runtime_get_sync() <-- cancels requested autosuspend
     |     /* some code running */
t3   | musb_gadget_pullup: pm_runtime_put() <-- suspends device (may happen before t4!)
     |
t4   | <- suspend is expected here, but device may be already suspended between t3 and t4

So use pm autosuspend in musb_gadget_pullup and prevent such situation

Change-Id: I8b9618c6d24bea3810c736f8fc0195802ce79c55
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
(cherry picked from commit fd5404d9033defa72dbbdaace600a67fcf9763bb)
video/sii9234.c: Fix defined but not used
hdcp/hdcp_top.c: Fix defined but not used
omap2430.c: Fix compile warning
usb: musb: musb_core.h: drop __deprecated flag
usb: musb: omap2430: musb_otg_notifier_work fix compile warning
musb_host.c: Fix musb_host_rx distinct pointer types lacks a cast
OMAP:MUSB:OTG: Disable MUSB DMA mode incase of DMA channel request failure

OMAP:MUSB:OTG: Disable MUSB DMA mode incase of DMA channel request failure

Currently in case of MUSB DMA channel request failure we are not
clearing MUSB_RXCSR_DMAENAB, MUSB_RXCSR_H_AUTOREQ and
MUSB_RXCSR_AUTOCLEAR bits of MUSB RXCSR of MUSB DMA. Which is
causing failure in receipt of data packets in next transfer.

Fix is to disable the MUSB DMA mode and related bits incase of
DMA channel request fails

Change-Id: Ie6caed6ef2a01ef647cc839c01724be32a247598
Signed-off-by: Mantesh Sarashetti <mantesh@ti.com>
USB: MUSB: Fix L3 error when USB-OTG plug/unplug to PC many times during Kernel boot.

L3 CUSTOM SRESP error appears on early stage of kernel boot and USB OTG repeating  plug/unplug  to PC.
Source:
[    2.258453] Master 0x0        MPU
[    2.258453] L4CFG OPCODE  0x00000002

Root cause is MUSB-OMAP2430 runtime suspending during PHY power on.

Fix:
pm_runtime_get_sync() is used.

modified:   drivers/usb/musb/omap2430.c

Change-Id: I59fa9db641caba811123f3724fbc17333f1458b1
Signed-off-by: x0169938 <vasyl.yushchyshen@ti.com>
USB: musb: do not proceed with interrupt completions if qh is not ready

It's not safe to modify hw_ep if qh is not ready.
This may corrupt data in musb_qh. In RX/TX completions this
may happen on SMP system with current musb host implementation
The main issue is with musb_giveback function. It unlocks and
and after that locks musb->lock so during this time
musb_qh data may be corrupted. This results in null-pointers
dereferences / programming of busy DMA channel / etc in
different places.

This often happens during unlinking URB for ISO and looks like:
CPU0                                  CPU1
...                                   musb_urb_dequeue
...                                      spin_lock_irqsave(&musb->lock)
...                                      (work with musb_qh)
...                                      musb_giveback
...                                         spin_unlock(&musb->lock)
generic_interrupt()                         ...
   spin_lock_irqsave(&musb->lock)           ...
   (work with musb_qh)                      ...
   spin_unlock_irqrestore(&musb->lock)      ...
...                                         spin_lock(&musb->lock)
...                                      (continues work with musb_qh)
...                                      spin_lock_irqrestore(&musb->lock)

Go out from completion if qh is not ready.

Change-Id: I9c9280a7ab7f8e89b2e8bf745800217f903108fc
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
(cherry picked from commit d0d4f29c2ac05a66a8b26c00ddd436e71519a1d5)
OMAP4+: HSI: hsi_char: fix write poll timeout issue

hsi_char driver may fail to return (POLLOUT | POLLWRNORM) after a write() has
occured. Instead it returns 0, causing the poll() to timeout.

This is due to a race condition between hsi_char_write() and if_hsi_notify().
Write callback can occur very fast in response to hsi_write() and may cause the
poll_event flag to be first set by if_hsi_notify() but then cleared by
hsi_char_write(), remaining to 0 forever and causing poll() timeout.

Fix is to clear the flag ahead of hsi_write to avoid this.

Change-Id: Iacd18f0448c1933a16b0a54db2204cd74fc259b2
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
Reported-by: Christian Auby <christian.auby@stericsson.com>
(cherry picked from commit 690e59b8530d2f9335c764707c11d549ba089d09)