Backport ipv6 addrconf.c and dependencies from 3.0.101
Fixes kernel nonstop spamming on ipv6 networks, preventing the device from entering in standby and generating ipv6 traffic affecting phone performance

The dmesg was like this:

<7>[11432.377075,1] p2p0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.377288,1] p2p0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.377441,1] wlan0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.377624,1] wlan0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.379455,1] p2p0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.379577,1] p2p0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.379821,1] wlan0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.380004,1] wlan0: GOT RA with prefix : rlft 0, vlft 921600,plft 230400, period 0
<7>[11432.381622,1] p2p0: RS timer expired.
<7>[11432.381927,1] p2p0: RS timer expired.
<7>[11432.382080,1] wlan0: RS timer expired.
<7>[11432.382202,1] wlan0: RS timer expired.

Change-Id: I03f76a03528e7b12da742c57fa18d0d49f8b08ee
OMAP4: HWMOD: UART1: disable smart-idle.

OMAP4: HWMOD: UART1: disable smart-idle.

UART module gets stuck in transition when smart-idle enabled.
By enabling HWMOD_SWSUP_SIDLE flag in UART1 HWMOD, ensures that
module's smart-idle feature is disabled and it is put to
forced-idle and no-idle during pm-runtime.

Seen similar issue with UART3 and was fixed by enabling
HWMOD_SWSUP_SIDLE flag in uart3 HWMOD.

Change-Id: Id1d97a498a5ffd7323be15be0ba8d0fc02e6df85
Signed-off-by: Ambresh K <ambresh@ti.com>
OMAP4: DSS: Implement workaround for Errata ID:i733.

OMAP4: DSS: Implement workaround for Errata ID:i733.

Description of Errata i733:
Due to wrong timings, all register accesses transitioning through the L4
interconnect toward DSS are not reliable.

Workaround:
DSS register access should be addressed through the L3 interconnect.

This change fixes errata by using L3 for access to DSS in dss_hwmod
instead of L4.

Silicon Versions Impacted:
OMAP4430 ES1.0, ES2.0, ES2.1, ES2.2, ES2.3
OMAP4460 ES1.0, ES1.1
OMAP4470 ES1.0

Change-Id: Ie087b861ee653a3beeacba74c3afe7b1a0490ed4
Co-author: Raghuveer Murthy <raghuveer.murthy@ti.com>
Signed-off-by: Mykhailo Denysiuk <x0172934@ti.com>
OMAP4: SAR: WA overwrite L3INIT CD mode to SW_SLEEP(1) in SAR

OMAP4: SAR: WA overwrite L3INIT CD mode to SW_SLEEP(1) in SAR

The wrong value of CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 2 (SW_WKUP)
has been stored in SAR during omap4_sar_save() execution and
causes power over consumption on OFF mode due to C2C operation.
It happens because the L3INIT CD need to be enabled during
omap4_sar_save() execution for proper USBHOST module context storing.

Problematic use case:
1) OMAP goes to sleep,
2) modem wakeup the C2C, the EMIF but the MPU is still sleeping
(as expected)
3) Modem release all his constraints, C2C is turned to OFF.
4) but OMAP never reach again OFF while we don't wakeup the CPU
(by a keypress for example), sys_clk is already ON and voltages
are not equal to 0. (OPP 50 for CORE_3 and retention voltages
for both VCORE1 and VCORE2).

As WA overwrite CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 0x1 (SW_SLEEP).

Change-Id: I2e453c07f61bab28a7213dd66044fd41a021961b
Signed-off-by: Arthur Cassegrain <a-cassegrain@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP4: PM: cold reset: wrong value is used to set LOGICRETSTATE

OMAP4: PM: cold reset: wrong value is used to set LOGICRETSTATE

The size of LOGICRETSTATE field is 1 bit, and pwrdm_set_logic_retst()
can accept only PWRDM_POWER_RET(0x1)/PWRDM_POWER_OFF(0x0) values.

Additional check of "pwrst" parameter and print out of error message
added in pwrdm_set_logic_retst() to minimize such issues in future.

Change-Id: I413e1e2ba3823574d4450225ed30cffb2cdfd565
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP: EMIF: fix LP_MODE_PWR_DN value definition

OMAP: EMIF: fix LP_MODE_PWR_DN value definition

According to TRM the EMIF Power-down mode is identified
by value 0x4 (EMIF_PWR_MGMT_CTRL.REG_LP_MODE)

Change-Id: I4d9b9534dea27ab4619af5b6d78de8ab14f0fead
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP4430: USB Host: Implement workaround for Errata i719

OMAP4430: USB Host: Implement workaround for Errata i719

The OMAP4 EHCI controller has the following defect (errata ID i719):

Title:
	HS USB: Multiple OFF Mode Transitions Introduce Corruption

Description:
	When the system enters off mode, the save-and-restore (SAR)
        process comes into play. When the save of the USB context
	occurs, an extra pulse of UTMI_root clock coming from USB
	DPLL is entering the IP, and generates a minor corruption.
	This corrupted context is saved and restored later.
	This corruption will impact the next use of the USB module:
	it could be while resuming a suspended device, or it could
	be upon the enumeration of a new device. The exact failure
	is not predictable: disconnection or stalls have been observed.
	TLL and external PHY modes are impacted.

WORKAROUND:
	During ON time, anytime before starting the next save sequence:
	• Set the CM_L3INIT_HSUSBHOST_CLKCTRL[1:0] MODULEMODE bit field
	  to 0x2 (enabled).
	• Wait 1 ms.
	• Set the same bit field back to 0x0 (disabled).

All OMAP4430 devices are impacted.

Change-Id: I63c866504ae3899c73755e6f6b00d388205c20bd
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP4430: USB Host: Implement workaround for Errata i687

OMAP4430: USB Host: Implement workaround for Errata i687

The OMAP4 EHCI controller has the following defect (errata ID i687):

Title:
	USB TLL Hold Timing Violation

Description:
	There is a timing hold violation on an internal logic on
	the clock USB TLL path resulting in a systematic connection
	failure on the TLL link

WORKAROUND:
	As part of workaround, next should be done:
	Set the I/O drive strength to 1.
	Depending which USB host subsystem is used,
	• Port B1 used: Set CONTROL.CONTROL_SMART2IO_PADCONF_2[11] USBB1_DR0_DS = 0x1
	• Port B2 used: Set CONTROL.CONTROL_SMART2IO_PADCONF_2[12] USBB2_DR0_DS = 0x1

All OMAP4430 devices are impacted.

Change-Id: Iba45e5a3b04a6180db3398edb8c00563f67f6105
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP4: USB: Update workaround for USB errata i719

ARM: OMAP4: USB: Update workaround for USB errata i719

Due to USB errata i719 the USB host save-and-restore context can be corrupted
if the device enters off mode more than two times without enabling the USB
host controller in between.

The corruption is occuring during the software save of the USB context which
occurs on entry to every off mode attempt. To avoid this problem only save the
USB context if the USB host controller has been enabled since the previous off
mode attempt. We do not need to save the USB context on every entry to off mode
if the USB controller has not been enabled.

Change-Id: I67e07963679af6494ef289eb10db09c0162d6f00
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
usb: ehci: fix the host wakeup state machine.

usb: ehci: fix the host wakeup state machine.

Current code enables host clocks and disables immediately
which can have side effects if port status change is not propagated
and clocks are cut, so enable clocks if ports are suspended
in all wakeup paths either from io-pad wakeup or through
bus resume in suspend path.

Change-Id: I5a03fcf46160176289d41cda6574c0c261a13e94
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
ARM: OMAP: HS USB Host: fix unbalanced pm calls

ARM: OMAP: HS USB Host: fix unbalanced pm calls

There is an issue with unbalanced pm calls.
Only EHCI or only OHCI works good but not together.
Issue appears when OHCI suspends whereas EHCI is active
or vice versa - anyway all HSUSBHOST goes to suspend.
This patch fixes this issue.

Change-Id: Ie4c4e4d4ff210c8ceeec4415569660f8646e8ed5
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
USB: OHCI: do not poll root hub status if HC is not running

USB: OHCI: do not poll root hub status if HC is not running

If the OHCI root hub is suspended the clocks may be
not provided to HW and we get errors on OHCI registers
access. So do not poll it in such cases (like is done
for EHCI)

Change-Id: Ic81833a87c479822fe3c7f23792ee7ac7154e248
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Merge: PM changes from omapzoom p-android-omap-3.0 kernel

0001-OMAP4-HWMOD-UART1-disable-smart-idle
0002-OMAP4-DSS-Implement-workaround-for-Errata-ID-i733
0003-OMAP4-SAR-WA-overwrite-L3INIT-CD-mode-to-SW_SLEEP-1
0004-OMAP4-PM-cold-reset-wrong-value-is-used-to-set-LOGIC
0005-OMAP-EMIF-fix-LP_MODE_PWR_DN-value-definition
0006-OMAP4430-USB-Host-Implement-workaround-for-Errata-i7
0007-OMAP4430-USB-Host-Implement-workaround-for-Errata-i6
0008-ARM-OMAP4-USB-Update-workaround-for-USB-errata-i719
0009-usb-ehci-fix-the-host-wakeup-state-machine
0010-ARM-OMAP-HS-USB-Host-fix-unbalanced-pm-calls
0011-USB-OHCI-do-not-poll-root-hub-status-if-HC-is-not-ru

Change-Id: I023afd5a6da3de3076efa0ff85ed64999199cfb5
rpmsg: resmgr: disable aux_clk_src in case of error

rpmsg: resmgr: disable aux_clk_src in case of error

If set_rate of aux_clk failed aux_clk_src was being left
enabled affecting the core OFF, fix the same.

Also avoid changing the return value of clk_set_rate.

Change-Id: I897d0669b43bf75ae49e9119ebfadf531bd585d5
Reported-by: Huzefa Kankroliwala <huzefank@ti.com>
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
rpmsg: omx: return actual user-provided bytes written in write

rpmsg: omx: return actual user-provided bytes written in write

The 'write' system call is expected to return the number of bytes
written back to userspace. The rpmsg omx driver adds a small packet
header when sending a message to the remote processor, and is
currently returning this header length as well in the driver's write
fop function. This results in the write call always returning more
bytes than what the user has requested. The header length is now
left out of the bytes returned back.

Change-Id: I7132001fbc6fb34d01913bb3c30f455626c91658
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: copy_from_user() errors should return -EFAULT

rpmsg: omx: copy_from_user() errors should return -EFAULT

Change-Id: Ib4a2d92dd3b8afa18e60019871cfea2e6b446a4d
Signed-off-by: David Schleef <ds@ti.com>
rpmsg: omx: return ENXIO in rpmsg_omx_write

rpmsg: omx: return ENXIO in rpmsg_omx_write

The error code, ENXIO is used in rpmsg_omx driver to indicate
a terminal error on the remote processor side. This status is
maintained during the recovery of the remote processor, while
the cdev gets reinitialized/recreated.

The rpmsg_omx's write file operation is currently not returning
this error. This has been added now to have it behave in the
same way as the read file operation.

Change-Id: I61d6e6c07aa39208d913da622ed32d809c51d409
Signed-off-by: Vidhoon Viswanathan <vidhoon@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: fix copy_to_user in register/unregister ioctls

rpmsg: omx: fix copy_to_user in register/unregister ioctls

The ION fd registration and deregistration ioctls has the
arguments reversed in the copy_to_user() calls. The same
has been fixed.

Also included a minor additional case for returning a NULL
ION handle back to user-space.

Change-Id: I9d45957f9b913fa1775e70618f0da82e914a41d6
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: send disconnect only if omx state is connected

rpmsg: omx: send disconnect only if omx state is connected

The rpmsg_omx driver sends a disconnect message automatically when the
driver's .release is called. This should be done only if a connection
has been established, otherwise just destroy the local end point.

Change-Id: I21b84aa6d91ae0d456f49cbe958f8e64caf691d5
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
rpmsg: omx: initialize completion event in rpmsg_omx_open

rpmsg: omx: initialize completion event in rpmsg_omx_open

An omx object is created when opening the rpmsg-omx device. However
the "reply_arrived" completion event is not initialized until the
connection message is sent across.

When the rpmsg_omx driver is removed (like in recovery), all pending
threads waiting on the "reply_arrived" are unblocked by a complete_all
call, however, if the rpmsg-omx device was only opened, such event is
not initialized yet, so the complete_all call will dereference a null
object causing a panic.

This patch moves the initialization of the "reply_arrived" completion
event to the open call, after the allocation of the omx object.

Change-Id: I92cf9cf5ac748456cb43bedc88fe1a8d80addd6c
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>