linux/drivers/rpmsg, branch v3.4.55

rpmsg: fix dependency on initialization order

2012-07-19T15:58:57Z

commit 9634252617441991b01dacaf4040866feecaf36f upstream. 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. Signed-off-by: Federico Fuga [ohad: rewrite the commit log] Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman

rpmsg: make sure inflight messages don't invoke just-removed callbacks

2012-07-16T16:03:52Z

commit 15fd943af50dbc5f7f4de33835795c72595f7bf4 upstream. 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. Reported-by: Fernando Guzman Lugo Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman

rpmsg: avoid premature deallocation of endpoints

2012-07-16T16:03:52Z

commit 5a081caa0414b9bbb82c17ffab9d6fe66edbb72f upstream. 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. Reported-by: Fernando Guzman Lugo Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman

rpmsg: fix build warning when dma_addr_t is 64-bit

2012-03-04T11:43:41Z

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: Mark Asselstine CC: Ohad Ben-Cohen CC: Arnd Bergmann Signed-off-by: Ohad Ben-Cohen

rpmsg: fix published buffer length in rpmsg_recv_done

2012-02-28T17:10:04Z

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: Ohad Ben-Cohen Cc: Grant Likely Cc: Arnd Bergmann Cc: Mark Grosen Cc: Suman Anna Cc: Fernando Guzman Lugo Cc: Rob Clark Cc: Ludovic BARRE Cc: Loic PALLARDY Cc: Omar Ramirez Luna

rpmsg: validate incoming message length before propagating

2012-02-28T17:10:04Z

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: Ohad Ben-Cohen Cc: Grant Likely Cc: Arnd Bergmann Cc: Mark Grosen Cc: Suman Anna Cc: Fernando Guzman Lugo Cc: Rob Clark Cc: Ludovic BARRE Cc: Loic PALLARDY Cc: Omar Ramirez Luna

rpmsg: fix name service endpoint leak

2012-02-28T17:09:54Z

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: Omar Ramirez Luna Signed-off-by: Ohad Ben-Cohen Cc: Grant Likely Cc: Arnd Bergmann Cc: Mark Grosen Cc: Suman Anna Cc: Fernando Guzman Lugo Cc: Rob Clark Cc: Ludovic BARRE Cc: Loic PALLARDY Cc: Omar Ramirez Luna

rpmsg: rename virtqueue_add_buf_gfp to virtqueue_add_buf

2012-02-22T16:28:48Z

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: Axel Lin Signed-off-by: Ohad Ben-Cohen

rpmsg: depend on EXPERIMENTAL

2012-02-22T16:28:43Z

There isn't any binary change in sight or evidence of any stability issue, but as we just begin to get traction we can't rule them out completely. To be on the safe side, let's mark rpmsg as EXPERIMENTAL, and remove it later on after we have several happy users. Signed-off-by: Ohad Ben-Cohen Cc: Stephen Boyd Cc: Rob Clark Cc: Mark Grosen Cc: Ludovic BARRE

rpmsg: add Kconfig menu

2012-02-08T20:54:49Z

Add a dedicated Kconfig menu for the rpmsg drivers, so they don't show up in the main driver menu. Signed-off-by: Ohad Ben-Cohen