1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
/*
* remote processor messaging bus
*
* Copyright (C) 2011 Texas Instruments, Inc.
* Copyright (C) 2011 Google, Inc.
*
* Ohad Ben-Cohen <ohad@wizery.com>
* Brian Swetland <swetland@google.com>
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#define pr_fmt(fmt) "%s: " fmt, __func__
#include <linux/kernel.h>
#include <linux/rpmsg.h>
/**
* rpmsg_create_ept() - create a new rpmsg_endpoint
* @rpdev: rpmsg channel device
* @cb: rx callback handler
* @priv: private data for the driver's use
* @chinfo: channel_info with the local rpmsg address to bind with @cb
*
* Every rpmsg address in the system is bound to an rx callback (so when
* inbound messages arrive, they are dispatched by the rpmsg bus using the
* appropriate callback handler) by means of an rpmsg_endpoint struct.
*
* This function allows drivers to create such an endpoint, and by that,
* bind a callback, and possibly some private data too, to an rpmsg address
* (either one that is known in advance, or one that will be dynamically
* assigned for them).
*
* Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
* is already created for them when they are probed by the rpmsg bus
* (using the rx callback provided when they registered to the rpmsg bus).
*
* So things should just work for simple drivers: they already have an
* endpoint, their rx callback is bound to their rpmsg address, and when
* relevant inbound messages arrive (i.e. messages which their dst address
* equals to the src address of their rpmsg channel), the driver's handler
* is invoked to process it.
*
* That said, more complicated drivers might do need to allocate
* additional rpmsg addresses, and bind them to different rx callbacks.
* To accomplish that, those drivers need to call this function.
*
* Drivers should provide their @rpdev channel (so the new endpoint would belong
* to the same remote processor their channel belongs to), an rx callback
* function, an optional private data (which is provided back when the
* rx callback is invoked), and an address they want to bind with the
* callback. If @addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
* dynamically assign them an available rpmsg address (drivers should have
* a very good reason why not to always use RPMSG_ADDR_ANY here).
*
* Returns a pointer to the endpoint on success, or NULL on error.
*/
struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
rpmsg_rx_cb_t cb, void *priv,
struct rpmsg_channel_info chinfo)
{
return rpdev->ops->create_ept(rpdev, cb, priv, chinfo);
}
EXPORT_SYMBOL(rpmsg_create_ept);
|
