idr_destroy() can destroy idr by itself and idr_remove_all() is being
deprecated.  Drop its usage.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Correct spelling typo in printk within various drivers.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We simplified virtqueue_add_buf(), make it clear in the callers.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

dma_alloc/free_coherent APIs requires the platform specific remoteproc
device as the device parameter. We are passing vdev->dev.parent to the
dma_free_coherent function which is the generic rproc device and it is
wrong, it has to be vdev->dev.parent->parent instead, same as when we
call dma_alloc_coherent function.
Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

When rpmsg drivers are built into the kernel, they must not initialize
before the rpmsg bus does, otherwise they'd trigger a BUG() in
drivers/base/driver.c line 169 (driver_register()).

To fix that, and to stop depending on arbitrary linkage ordering of
those built-in rpmsg drivers, we make the rpmsg bus initialize at
subsys_initcall.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NFederico Fuga <fuga@studiofuga.com>
[ohad: rewrite the commit log]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).

With this in hand, the resulting device hierarchy might then look like:

omap-rproc.0
 |
 - remoteproc0  <---- new !
    |
    - virtio0
    |
    - virtio1
       |
       - rpmsg0
       |
       - rpmsg1
       |
       - rpmsg2

Where:
- omap-rproc.0 is the low level device that's bound to the
  driver which invokes rproc_register()
- remoteproc0 is the result of this patch, and will be added by the
  remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
  when it realizes that they are supported by the firmware
  of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
  channels, and are registerd by the rpmsg bus when it gets notified
  about their existence

Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new "remoteproc" type, to which this new generic remoteproc.x
  device belong to.
- adds a super simple enumeration method for the indices of the
  remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
  instead of the low level platform-specific device
- updates all dma_* allocations to use the parent of remoteproc.x (where
  the platform-specific memory pools, most commonly CMA, are to be found)

Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
  new "remoteproc" type
- all remoteproc log messages will now carry a common name prefix
  instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
  refcounting (see subsequent patch)

Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
with the (upcoming) runtime PM support for remoteproc.

Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

When inbound messages arrive, rpmsg core looks up their associated
endpoint (by destination address) and then invokes their callback.

We've made sure that endpoints will never be de-allocated after they
were found by rpmsg core, but we also need to protect against the
(rare) scenario where the rpmsg driver was just removed, and its
callback function isn't available anymore.

This is achieved by introducing a callback mutex, which must be taken
before the callback is invoked, and, obviously, before it is removed.

Cc: stable <stable@vger.kernel.org>
Reported-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

When an inbound message arrives, the rpmsg core looks up its
associated endpoint and invokes the registered callback.

If a message arrives while its endpoint is being removed (because
the rpmsg driver was removed, or a recovery of a remote processor
has kicked in) we must ensure atomicity, i.e.:

- Either the ept is removed before it is found

or

- The ept is found but will not be freed until the callback returns

This is achieved by maintaining a per-ept reference count, which,
when drops to zero, will trigger deallocation of the ept.

With this in hand, it is now forbidden to directly deallocate
epts once they have been added to the endpoints idr.

Cc: stable <stable@vger.kernel.org>
Reported-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

dev_dbg() in rpmsg_probe() made use of the %x formatting that
expects an 'unsigned int' which dma_addr_t is not in cases where
dma_addr_t is 64-bit (CONFIG_ARCH_DMA_ADDR_T_64BIT). Casting to
a 'unsigned long long' and using %llx will avoid this.
Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com>
CC: Ohad Ben-Cohen <ohad@wizery.com>
CC: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

After processing an incoming message, always publish the real size
of its containing buffer when putting it back on the available rx ring.

Using any different value might erroneously limit the remote processor
(leading it to think the buffer is smaller than it really is).
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>

When an inbound message arrives, validate its reported length before
propagating it, otherwise buggy (or malicious) remote processors might
trick us into accessing memory which we really shouldn't.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>

The name service endpoint wasn't destroyed, so fix it.

This is achieved by introducing an internal __rpmsg_destroy_ept
function which doesn't assume the given ept is bound to an rpmsg
channel (much like the existing __rpmsg_create_ept).

This is needed because the name service ept belongs to the rpmsg bus,
and is never bound with a specific rpdev.
Reported-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>

Since commit 7bb7aef2 "virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf",
virtqueue_add_buf_gfp is already rename to virtqueue_add_buf now.

This patch fixes below build error:
 CC [M]  drivers/rpmsg/virtio_rpmsg_bus.o
drivers/rpmsg/virtio_rpmsg_bus.c: In function 'rpmsg_send_offchannel_raw':
drivers/rpmsg/virtio_rpmsg_bus.c:723: error: implicit declaration of function 'virtqueue_add_buf_gfp'
make[2]: *** [drivers/rpmsg/virtio_rpmsg_bus.o] Error 1
make[1]: *** [drivers/rpmsg] Error 2
make: *** [drivers] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

Add a virtio-based inter-processor communication bus, which enables
kernel drivers to communicate with entities, running on remote
processors, over shared memory using a simple messaging protocol.

Every pair of AMP processors share two vrings, which are used to send
and receive the messages over shared memory.

The header of every message sent on the rpmsg bus contains src and dst
addresses, which make it possible to multiplex several rpmsg channels on
the same vring.

Every rpmsg channel is a device on this bus. When a channel is added,
and an appropriate rpmsg driver is found and probed, it is also assigned
a local rpmsg address, which is then bound to the driver's callback.

When inbound messages carry the local address of a bound driver,
its callback is invoked by the bus.

This patch provides a kernel interface only; user space interfaces
will be later exposed by kernel users of this rpmsg bus.

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au> (virtio_ids.h)
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>