net/rpmsg: fix memory leak of vrp_channels radix tree

The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The usage relies on leveraging
the socket API's connect for Tx sockets and bind for Rx sockets
to exchange messages to/from a remote processor. The MessageQ
stack relies on the Tx sockets leveraging a single rpmsg_channel
device published from the remote processor firmware. All the
published devices from a remote processor are stored in a
corresponding vrp_channels radix tree node, but this is not
freed at all, causing a memory leak.

Fix the memory leak by deleting the radix tree element and
the memory associated with the radix tree node during the
driver's remove.

NOTE:
The MessageQ design relies on only a single published rpmsg
channel device, and as such, this fix deletes the tree node
when that device is unregistered. This needs to be fixed if
multiple devices were to be published from the firmware image.

Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: add a check to not support multiple published channels

The TI IPC MessageQ stack usage of the AF_RPMSG socket interface
is not really designed to handle multiple rpmsg-proto devices
published from the same remote processor, even though there are
no such restrictions imposed by the rpmsg bus infrastructure. So,
add an error check for the same.

Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: use a list to track all connected sockets

The rpmsg proto driver uses a single rpmsg_channel device published
from a remote processor to transmit all socket-based messages intended
for that remote processor. There can be any number of Tx sockets to
a particular remote processor, and a connection is established using
the connect() socket API. The current implementation stores the
connected socket pointer in the private field of the rpmsg_channel
device's endpoint (ept->priv), but this means a subsequent connection
will overwrite the previously stored socket pointer.

Create and add a list pointer to the endpoint's private field instead,
and add all the connected sockets to this list. Note that this list is
maintained only for Tx sockets, as the Rx sockets create their own
rpmsg_channel and store their socket pointer in the corresponding
end-point's private field.

A published rpmsg channel will be auto-removed and recreated if the
associated remote processor goes through an error recovery process,
and the rpmsg_channel device's private field can be used to mark
an error status for all the sockets associated with that rpmsg
channel. The list allows all the Tx connected sockets to be marked
at once during the removal of the published rpmsg_channel device.
The error status can be used to gracefully deny any further
transmissions on those sockets.

Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: store remote processor id in rpmsg_socket

The rpmsg_proto depends on rpmsg_sock_get_proc_id() to retrieve
the remote processor address at runtime, but this relies on
retrieving the address based on looking up the underlying parent
virtio device of the associated rpmsg channel. This can not be
always relied on, as the virtio devices can be deleted and
recreated during a recovery of a remote processor.

Add a new field 'rproc_id' to the rpmsg_socket structure, and
use this field to store the remote processor address during
the connect and bind socket calls. The rpmsg sockets leverage
connect for Tx sockets and bind for Rx sockets to exchange
messages to/from a remote processor. This field allows runtime
lookup of the processor id in any of the operations on the
socket, without being burdened with the life cycle of the
underlying rpmsg or virtio devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: set error status on open sockets after recovery

The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the
TI IPC MessageQ stack. The rpmsg proto driver uses a single
rpmsg_channel device published from a remote processor to transmit
and receive all socket-based messages to/from that remote processor.
A published rpmsg channel will be auto-removed and recreated if the
associated remote processor goes through an error recovery process.
Any existing open sockets (both Tx and Rx) are oblivious if the
underlying rpmsg channel has been removed, and any further
operations on such sockets can create a kernel crash (like on
Tx sockets on send call) due to invalid pointer dereferences.

This patch adds the error recovery support to the rpmsg-proto
driver. A new error status (RPMSG_ERROR) is set on all these
open sockets, so that the userspace can leverage this to perform
appropriate cleanup or recovery steps. This new status is also
useful in checking the valid state of a socket and preventing
any kernel crashes.

The logic is asymmetric because of the difference in usage of the
underlying rpmsg channel device in each socket. All the Tx sockets
use the one-time published rpmsg_channel devices for transmissions,
while each of the Rx sockets have their own rpmsg_channel device
for receiving messages. During error recovery, the virtio core
also removes the devices created by the Rx sockets, while the open
sockets themselves can be freed up anytime either by the userspace
closing them or through an automatic close when the process is
terminated/closed.

Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets

The rpmsg proto driver uses a single rpmsg_channel device
published from a remote processor to transmit all socket-based
messages intended for that remote processor. This channel will
be auto-removed and recreated if the remote processor goes
through an error recovery process. Any connected sockets are
marked with an error status, and further transmissions on these
connected sockets should gracefully return an error. This error
condition is specifically checked for and a new error ESHUTDOWN
is returned back to userspace to differentiate it from
transmissions on an unconnected socket.

Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y

Pull in the updated rpmsg client drivers feature branch that
includes the fix for a memory leak and multiple bug fixes
during error recovery with active open sockets.

* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
  net/rpmsg: set error status on open sockets after recovery
  net/rpmsg: store remote processor id in rpmsg_socket
  net/rpmsg: use a list to track all connected sockets
  net/rpmsg: add a check to not support multiple published channels
  net/rpmsg: fix memory leak of vrp_channels radix tree

Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux-3.14.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y

* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
  net/rpmsg: set error status on open sockets after recovery
  net/rpmsg: store remote processor id in rpmsg_socket
  net/rpmsg: use a list to track all connected sockets
  net/rpmsg: add a check to not support multiple published channels
  net/rpmsg: fix memory leak of vrp_channels radix tree

Signed-off-by: Dan Murphy <DMurphy@ti.com>
ti_config_fragments/all_valid_socs.cfg: Only enable the SoCs that we actually support

Remove additional overhead code when we support v6 instruction set and
platforms such as OMAP3/4 which our release is not really targetting.

This also makes it clear which specific SoCs the build is meant for.

Specific SoC only config fragments override this base configuration.

Signed-off-by: Nishanth Menon <nm@ti.com>
ti_config_fragments: add a DRA7 only build configuration

Allow distros that use DRA7-only to enable LPAE to address larger
regions of memory as needed. This may also allow us to enable cortex-a15
only features later on as needed.

Cc: Somnath Mukherjee <somnath@ti.com>
Cc: Praneeth Bajjuri <praneeth@ti.com>
Cc: Vishal Mahaveer <vishalm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

With consolidated code, now we can add the required hooks for
DRA7 to enable power management.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: minor modifications]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
drm/omap: use DRM_ERROR_RATELIMITED() for error irqs

omapdrm uses normal DRM_ERROR() print when the HW reports an error. As
we sometimes may get a flood of errors, let's rather use
DRM_ERROR_RATELIMITED().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
drm/omap: fix race with error_irq

omapdrm tries to avoid error floods by unregistering the error irq when
an error happens, and then registering the error irq again later.
However, the code is racy, as it sometimes tries to unregister the error
irq when it's already unregistered, leading to WARN().

Also, the code only registers the error irq again when something is done
on that particular output, i.e. if only TV is used to flip the buffers,
and LCD is showing a same buffer, an error on LCD will cause the LCD
error irq to be unregistered and never registered again.

To fix this, let's keep the error irqs always enabled and trust the
DRM_ERROR_RATELIMITED to limit the flood.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
drm/omap: only ignore DIGIT SYNC LOST for TV output

We need to ignore DIGIT SYNC LOST error when enabling/disabling TV
output. The code does that, but it ignores the DIGI SYNC LOST when
enabling any output. Normally this does no harm, but it could make us
miss DIGIT SYNC LOST on some rare occasions.

Fix the code to only ignore DIGIT SYNC LOST when enabling/disabling TV.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: workaround for MFLAG + NV12 issue

It was found that having two displays enabled and having an NV12 overlay
on one of the displays will cause underflows/synclosts. Debugging this
pointed to some issue with MFLAG.

It is unclear why this issue is happening, but it looks like there is a
HW bug related to MFLAG and FIFO management. Disabling MFLAG makes this
issue go away (but then we lose the benefit of MFLAG), and forcing MFLAG
always on makes the issue go away.

Also, using certain values for MFLAG_START, MFLAG thresholds and PRELOAD
makes the issue go away, but there was no obvious logic to which values
work and which don't.

As a workaround until more information about this is found, force MFLAG
always on to make NV12 usable.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ARM: DRA7: Add hook in SoC initcalls to enable pm initialization
  ti_config_fragments: add a DRA7 only build configuration
  ti_config_fragments/all_valid_socs.cfg: Only enable the SoCs that we actually support

Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y

TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y

* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
  OMAPDSS: workaround for MFLAG + NV12 issue
  drm/omap: only ignore DIGIT SYNC LOST for TV output
  drm/omap: fix race with error_irq
  drm/omap: use DRM_ERROR_RATELIMITED() for error irqs

Signed-off-by: Dan Murphy <DMurphy@ti.com>
Revert "drivers/net: Disable UFO through virtio"

This reverts commit 2b52d6c6beda6308ba95024a1eba1dfc9515ba32 which was
commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 upstream.

Ben writes:

	Please drop this patch for 3.14 and 3.17.  It causes problems
	for migration of VMs and we're probably going to revert part of
	this.  The following patch ("drivers/net, ipv6: Select IPv6
	fragment idents for virtio UFO packets") might no longer apply,
	in which case you can drop that as well until we have this
	sorted out upstream.

Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ip6_tunnel: Use ip6_tnl_dev_init as the ndo_init function.

[ Upstream commit 6c6151daaf2d8dc2046d9926539feed5f66bf74e ]

ip6_tnl_dev_init() sets the dev->iflink via a call to
ip6_tnl_link_config(). After that, register_netdevice()
sets dev->iflink = -1. So we loose the iflink configuration
for ipv6 tunnels. Fix this by using ip6_tnl_dev_init() as the
ndo_init function. Then ip6_tnl_dev_init() is called after
dev->iflink is set to -1 from register_netdevice().

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vti6: Use vti6_dev_init as the ndo_init function.

[ Upstream commit 16a0231bf7dc3fb37e9b1f1cb1a277dc220b5c5e ]

vti6_dev_init() sets the dev->iflink via a call to
vti6_link_config(). After that, register_netdevice()
sets dev->iflink = -1. So we loose the iflink configuration
for vti6 tunnels. Fix this by using vti6_dev_init() as the
ndo_init function. Then vti6_dev_init() is called after
dev->iflink is set to -1 from register_netdevice().

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>