usb: otg: OMAP4: Fix the omap4430_phy_set_clk function

usb: otg: OMAP4: Fix the omap4430_phy_set_clk function

If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.

Fix this - so now if we try to enable already enabled clocks
it works correctly.

Change-Id: I657e13651c908eaa7caf2fd4ff86028c50902fd6
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
GPIO: OMAP2+: On suspend don't wakeup on non-wakeupable interrupts.

GPIO: OMAP2+: On suspend don't wakeup on non-wakeupable interrupts.

While in suspend, device should only be woken-up from those gpio
pins, who has explicitly marked itself has wakeup capable through
enable_irq_wake() functions from respective drivers.

In current implementation, it address the issue where interrupts
were lost when system had entered deeper c-state. So in CpuIdle
path all the pins with interrupts enabled where marked has wakeup
capable to get the system out of deeper c-states.
With this approach, it is observed that lots of spurious
interrupts are waking system from suspend, even though they not
suppose wake the device.

So based on, whether prepare idle is called from CpuIdle or
suspend mark gpio wakeup capable.

Change-Id: Ib3f9be6e56c0656f4b8736861740ed0b4394384f
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Hema Kalliguddi <hemahk@ti.com>
GPIO: OMAP: Fix the sequence to clear the IRQ status

GPIO: OMAP: Fix the sequence to clear the IRQ status

The recommended way to clear the GPIO IRQ status is to:

- Enable the IRQ
- clear the status

If this above sequence is not followed, i.e., if the status
is cleared after disabling the IRQ then sWAKEUP will not be
cleared and gates the module transition.

Change-Id: I8bd1b820ac8be70530cd6430f26ce541bfd3f9d9
Signed-off-by: Huzefa Kankroliwala <huzefank@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Andrii Anisov <andrii.anisov@ti.com>
omap4-common: prevent lis3dh overwriting arbitrary kernel memory

this fixes a use-after-free which was previously "worked-around"
in commit b1fdf107c3432d869fe80da75a60203917d69cea. This actually
made the situation worse.

Change-Id: Ie200de1a255eb0db91d601d56f77fe06cff48460
Revert "moto lis3dh: use i2c block API"

This reverts commit b1fdf107c3432d869fe80da75a60203917d69cea.

This "fix" used to initialize the flags-field in the client-
structure with 0 so the i2c-transfer was successful.
But this was only needed because the client-structure was
a pointer to a structure on the stack of the init-function.
Writing the flags-field actually overwrote random kernel memory
at that location.