This revision addresses comments received from the previous revision,
i.e V6. Please see details below.
It starts by making the RPMSG protocol transport agnostic by
moving the headers it uses to generic types and using those in the
current implementation. From there it re-uses the work that Arnaud
published[1] to make the name service modular.
Tested on stm32mp157 with the RPMSG client sample application. Applies
cleanly on rpmsg-next.
Thanks,
Mathieu
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
-------
New for V7:
- Fixed error path in rpmsg_probe() as reported by Guennadi
Arnaud Pouliquen (4):
rpmsg: virtio: Rename rpmsg_create_channel
rpmsg: core: Add channel creation internal API
rpmsg: virtio: Add rpmsg channel device ops
rpmsg: Turn name service into a stand alone driver
Mathieu Poirier (4):
rpmsg: Introduce __rpmsg{16|32|64} types
rpmsg: virtio: Move from virtio to rpmsg byte conversion
rpmsg: Move structure rpmsg_ns_msg to header file
rpmsg: Make rpmsg_{register|unregister}_device() public
drivers/rpmsg/Kconfig | 9 ++
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/rpmsg_core.c | 44 ++++++++
drivers/rpmsg/rpmsg_internal.h | 14 ++-
drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
include/linux/rpmsg.h | 63 ++++++++++-
include/linux/rpmsg/byteorder.h | 67 +++++++++++
include/linux/rpmsg/ns.h | 45 ++++++++
include/uapi/linux/rpmsg_types.h | 11 ++
10 files changed, 439 insertions(+), 127 deletions(-)
create mode 100644 drivers/rpmsg/rpmsg_ns.c
create mode 100644 include/linux/rpmsg/byteorder.h
create mode 100644 include/linux/rpmsg/ns.h
create mode 100644 include/uapi/linux/rpmsg_types.h
--
2.25.1
Use rpmsg byte conversion functions in order for the RPMSG
headers and generic functions to be used by external entities.
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Arnaud Pouliquen <[email protected]>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 53 +++++++++++++++++---------------
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 7d7ed4e5cce7..5259fbbc8e68 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -19,11 +19,11 @@
#include <linux/mutex.h>
#include <linux/of_device.h>
#include <linux/rpmsg.h>
+#include <linux/rpmsg/byteorder.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/virtio.h>
-#include <linux/virtio_byteorder.h>
#include <linux/virtio_ids.h>
#include <linux/virtio_config.h>
#include <linux/wait.h>
@@ -85,11 +85,11 @@ struct virtproc_info {
* Every message sent(/received) on the rpmsg bus begins with this header.
*/
struct rpmsg_hdr {
- __virtio32 src;
- __virtio32 dst;
- __virtio32 reserved;
- __virtio16 len;
- __virtio16 flags;
+ __rpmsg32 src;
+ __rpmsg32 dst;
+ __rpmsg32 reserved;
+ __rpmsg16 len;
+ __rpmsg16 flags;
u8 data[];
} __packed;
@@ -107,8 +107,8 @@ struct rpmsg_hdr {
*/
struct rpmsg_ns_msg {
char name[RPMSG_NAME_SIZE];
- __virtio32 addr;
- __virtio32 flags;
+ __rpmsg32 addr;
+ __rpmsg32 flags;
} __packed;
/**
@@ -341,8 +341,8 @@ static int virtio_rpmsg_announce_create(struct rpmsg_device *rpdev)
struct rpmsg_ns_msg nsm;
strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
- nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
- nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_CREATE);
+ nsm.addr = cpu_to_rpmsg32(rpdev, rpdev->ept->addr);
+ nsm.flags = cpu_to_rpmsg32(rpdev, RPMSG_NS_CREATE);
err = rpmsg_sendto(rpdev->ept, &nsm, sizeof(nsm), RPMSG_NS_ADDR);
if (err)
@@ -365,8 +365,8 @@ static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
struct rpmsg_ns_msg nsm;
strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
- nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
- nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_DESTROY);
+ nsm.addr = cpu_to_rpmsg32(rpdev, rpdev->ept->addr);
+ nsm.flags = cpu_to_rpmsg32(rpdev, RPMSG_NS_DESTROY);
err = rpmsg_sendto(rpdev->ept, &nsm, sizeof(nsm), RPMSG_NS_ADDR);
if (err)
@@ -425,6 +425,7 @@ static struct rpmsg_device *rpmsg_create_channel(struct virtproc_info *vrp,
rpdev->src = chinfo->src;
rpdev->dst = chinfo->dst;
rpdev->ops = &virtio_rpmsg_ops;
+ rpdev->little_endian = virtio_is_little_endian(vrp->vdev);
/*
* rpmsg server channels has predefined local address (for now),
@@ -618,10 +619,10 @@ static int rpmsg_send_offchannel_raw(struct rpmsg_device *rpdev,
}
}
- msg->len = cpu_to_virtio16(vrp->vdev, len);
+ msg->len = cpu_to_rpmsg16(rpdev, len);
msg->flags = 0;
- msg->src = cpu_to_virtio32(vrp->vdev, src);
- msg->dst = cpu_to_virtio32(vrp->vdev, dst);
+ msg->src = cpu_to_rpmsg32(rpdev, src);
+ msg->dst = cpu_to_rpmsg32(rpdev, dst);
msg->reserved = 0;
memcpy(msg->data, data, len);
@@ -710,14 +711,15 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
{
struct rpmsg_endpoint *ept;
struct scatterlist sg;
- unsigned int msg_len = virtio16_to_cpu(vrp->vdev, msg->len);
+ bool little_endian = virtio_is_little_endian(vrp->vdev);
+ unsigned int msg_len = __rpmsg16_to_cpu(little_endian, msg->len);
int err;
dev_dbg(dev, "From: 0x%x, To: 0x%x, Len: %d, Flags: %d, Reserved: %d\n",
- virtio32_to_cpu(vrp->vdev, msg->src),
- virtio32_to_cpu(vrp->vdev, msg->dst), msg_len,
- virtio16_to_cpu(vrp->vdev, msg->flags),
- virtio32_to_cpu(vrp->vdev, msg->reserved));
+ __rpmsg32_to_cpu(little_endian, msg->src),
+ __rpmsg32_to_cpu(little_endian, msg->dst), msg_len,
+ __rpmsg16_to_cpu(little_endian, msg->flags),
+ __rpmsg32_to_cpu(little_endian, msg->reserved));
#if defined(CONFIG_DYNAMIC_DEBUG)
dynamic_hex_dump("rpmsg_virtio RX: ", DUMP_PREFIX_NONE, 16, 1,
msg, sizeof(*msg) + msg_len, true);
@@ -736,7 +738,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
/* use the dst addr to fetch the callback of the appropriate user */
mutex_lock(&vrp->endpoints_lock);
- ept = idr_find(&vrp->endpoints, virtio32_to_cpu(vrp->vdev, msg->dst));
+ ept = idr_find(&vrp->endpoints, __rpmsg32_to_cpu(little_endian, msg->dst));
/* let's make sure no one deallocates ept while we use it */
if (ept)
@@ -750,7 +752,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
if (ept->cb)
ept->cb(ept->rpdev, msg->data, msg_len, ept->priv,
- virtio32_to_cpu(vrp->vdev, msg->src));
+ __rpmsg32_to_cpu(little_endian, msg->src));
mutex_unlock(&ept->cb_lock);
@@ -830,6 +832,7 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
struct rpmsg_channel_info chinfo;
struct virtproc_info *vrp = priv;
struct device *dev = &vrp->vdev->dev;
+ bool little_endian = virtio_is_little_endian(vrp->vdev);
int ret;
#if defined(CONFIG_DYNAMIC_DEBUG)
@@ -858,13 +861,13 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
strncpy(chinfo.name, msg->name, sizeof(chinfo.name));
chinfo.src = RPMSG_ADDR_ANY;
- chinfo.dst = virtio32_to_cpu(vrp->vdev, msg->addr);
+ chinfo.dst = __rpmsg32_to_cpu(little_endian, msg->addr);
dev_info(dev, "%sing channel %s addr 0x%x\n",
- virtio32_to_cpu(vrp->vdev, msg->flags) & RPMSG_NS_DESTROY ?
+ __rpmsg32_to_cpu(little_endian, msg->flags) & RPMSG_NS_DESTROY ?
"destroy" : "creat", msg->name, chinfo.dst);
- if (virtio32_to_cpu(vrp->vdev, msg->flags) & RPMSG_NS_DESTROY) {
+ if (__rpmsg32_to_cpu(little_endian, msg->flags) & RPMSG_NS_DESTROY) {
ret = rpmsg_unregister_device(&vrp->vdev->dev, &chinfo);
if (ret)
dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
--
2.25.1
Make function rpmsg_register_device() and rpmsg_unregister_device()
functions public so that they can be used by other clients. While
doing so get rid of two obsolete function, i.e register_rpmsg_device()
and unregister_rpmsg_device(), to prevent confusion.
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Arnaud Pouliquen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
---
drivers/rpmsg/rpmsg_internal.h | 4 ----
include/linux/rpmsg.h | 12 ++++++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index f1de73e0f2d6..a76c344253bf 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -74,10 +74,6 @@ struct rpmsg_endpoint_ops {
poll_table *wait);
};
-int rpmsg_register_device(struct rpmsg_device *rpdev);
-int rpmsg_unregister_device(struct device *parent,
- struct rpmsg_channel_info *chinfo);
-
struct device *rpmsg_find_device(struct device *parent,
struct rpmsg_channel_info *chinfo);
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index faf2daff6238..a5db828b2420 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -164,8 +164,9 @@ static inline __rpmsg64 cpu_to_rpmsg64(struct rpmsg_device *rpdev, u64 val)
#if IS_ENABLED(CONFIG_RPMSG)
-int register_rpmsg_device(struct rpmsg_device *dev);
-void unregister_rpmsg_device(struct rpmsg_device *dev);
+int rpmsg_register_device(struct rpmsg_device *rpdev);
+int rpmsg_unregister_device(struct device *parent,
+ struct rpmsg_channel_info *chinfo);
int __register_rpmsg_driver(struct rpmsg_driver *drv, struct module *owner);
void unregister_rpmsg_driver(struct rpmsg_driver *drv);
void rpmsg_destroy_ept(struct rpmsg_endpoint *);
@@ -188,15 +189,18 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
#else
-static inline int register_rpmsg_device(struct rpmsg_device *dev)
+static inline int rpmsg_register_device(struct rpmsg_device *rpdev)
{
return -ENXIO;
}
-static inline void unregister_rpmsg_device(struct rpmsg_device *dev)
+static inline int rpmsg_unregister_device(struct device *parent,
+ struct rpmsg_channel_info *chinfo)
{
/* This shouldn't be possible */
WARN_ON(1);
+
+ return -ENXIO;
}
static inline int __register_rpmsg_driver(struct rpmsg_driver *drv,
--
2.25.1
Move structure rpmsg_ns_msg to its own header file so that
it can be used by other entities.
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Arnaud Pouliquen <[email protected]>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 32 +-----------------------
include/linux/rpmsg/ns.h | 42 ++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 31 deletions(-)
create mode 100644 include/linux/rpmsg/ns.h
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 5259fbbc8e68..20d0cf909bea 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -20,6 +20,7 @@
#include <linux/of_device.h>
#include <linux/rpmsg.h>
#include <linux/rpmsg/byteorder.h>
+#include <linux/rpmsg/ns.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
#include <linux/sched.h>
@@ -93,34 +94,6 @@ struct rpmsg_hdr {
u8 data[];
} __packed;
-/**
- * struct rpmsg_ns_msg - dynamic name service announcement message
- * @name: name of remote service that is published
- * @addr: address of remote service that is published
- * @flags: indicates whether service is created or destroyed
- *
- * This message is sent across to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
- char name[RPMSG_NAME_SIZE];
- __rpmsg32 addr;
- __rpmsg32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
- RPMSG_NS_CREATE = 0,
- RPMSG_NS_DESTROY = 1,
-};
/**
* struct virtio_rpmsg_channel - rpmsg channel descriptor
@@ -167,9 +140,6 @@ struct virtio_rpmsg_channel {
*/
#define RPMSG_RESERVED_ADDRESSES (1024)
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR (53)
-
static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/rpmsg/ns.h b/include/linux/rpmsg/ns.h
new file mode 100644
index 000000000000..73ecc91dc26f
--- /dev/null
+++ b/include/linux/rpmsg/ns.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_RPMSG_NS_H
+#define _LINUX_RPMSG_NS_H
+
+#include <linux/mod_devicetable.h>
+#include <linux/rpmsg/byteorder.h>
+#include <linux/types.h>
+
+/**
+ * struct rpmsg_ns_msg - dynamic name service announcement message
+ * @name: name of remote service that is published
+ * @addr: address of remote service that is published
+ * @flags: indicates whether service is created or destroyed
+ *
+ * This message is sent across to publish a new service, or announce
+ * about its removal. When we receive these messages, an appropriate
+ * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
+ * or ->remove() handler of the appropriate rpmsg driver will be invoked
+ * (if/as-soon-as one is registered).
+ */
+struct rpmsg_ns_msg {
+ char name[RPMSG_NAME_SIZE];
+ __rpmsg32 addr;
+ __rpmsg32 flags;
+} __packed;
+
+/**
+ * enum rpmsg_ns_flags - dynamic name service announcement flags
+ *
+ * @RPMSG_NS_CREATE: a new remote service was just created
+ * @RPMSG_NS_DESTROY: a known remote service was just destroyed
+ */
+enum rpmsg_ns_flags {
+ RPMSG_NS_CREATE = 0,
+ RPMSG_NS_DESTROY = 1,
+};
+
+/* Address 53 is reserved for advertising remote services */
+#define RPMSG_NS_ADDR (53)
+
+#endif
--
2.25.1
From: Arnaud Pouliquen <[email protected]>
Make the RPMSG name service announcement a stand alone driver so that it
can be reused by other subsystems. It is also the first step in making the
functionatlity transport independent, i.e that is not tied to virtIO.
Co-developed-by: Mathieu Poirier <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Co-developed-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Arnaud Pouliquen <[email protected]>
---
drivers/rpmsg/Kconfig | 9 +++
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++++++++++++
drivers/rpmsg/virtio_rpmsg_bus.c | 87 +++++----------------
include/linux/rpmsg/ns.h | 3 +
5 files changed, 159 insertions(+), 67 deletions(-)
create mode 100644 drivers/rpmsg/rpmsg_ns.c
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index f96716893c2a..0b4407abdf13 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -15,6 +15,14 @@ config RPMSG_CHAR
in /dev. They make it possible for user-space programs to send and
receive rpmsg packets.
+config RPMSG_NS
+ tristate "RPMSG name service announcement"
+ depends on RPMSG
+ help
+ Say Y here to enable the support of the name service announcement
+ channel that probes the associated RPMsg device on remote endpoint
+ service announcement.
+
config RPMSG_MTK_SCP
tristate "MediaTek SCP"
depends on MTK_SCP
@@ -62,6 +70,7 @@ config RPMSG_VIRTIO
tristate "Virtio RPMSG bus driver"
depends on HAS_DMA
select RPMSG
+ select RPMSG_NS
select VIRTIO
endmenu
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ffe932ef6050..8d452656f0ee 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_RPMSG) += rpmsg_core.o
obj-$(CONFIG_RPMSG_CHAR) += rpmsg_char.o
+obj-$(CONFIG_RPMSG_NS) += rpmsg_ns.o
obj-$(CONFIG_RPMSG_MTK_SCP) += mtk_rpmsg.o
qcom_glink-objs := qcom_glink_native.o qcom_glink_ssr.o
obj-$(CONFIG_RPMSG_QCOM_GLINK) += qcom_glink.o
diff --git a/drivers/rpmsg/rpmsg_ns.c b/drivers/rpmsg/rpmsg_ns.c
new file mode 100644
index 000000000000..762ff1ae279f
--- /dev/null
+++ b/drivers/rpmsg/rpmsg_ns.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ */
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/rpmsg.h>
+#include <linux/rpmsg/ns.h>
+#include <linux/slab.h>
+
+#include "rpmsg_internal.h"
+
+/**
+ * rpmsg_ns_register_device() - register name service device based on rpdev
+ * @rpdev: prepared rpdev to be used for creating endpoints
+ *
+ * This function wraps rpmsg_register_device() preparing the rpdev for use as
+ * basis for the rpmsg name service device.
+ */
+int rpmsg_ns_register_device(struct rpmsg_device *rpdev)
+{
+ strcpy(rpdev->id.name, "rpmsg_ns");
+ rpdev->driver_override = "rpmsg_ns";
+ rpdev->src = RPMSG_NS_ADDR;
+ rpdev->dst = RPMSG_NS_ADDR;
+
+ return rpmsg_register_device(rpdev);
+}
+EXPORT_SYMBOL(rpmsg_ns_register_device);
+
+/* invoked when a name service announcement arrives */
+static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
+ void *priv, u32 src)
+{
+ struct rpmsg_ns_msg *msg = data;
+ struct rpmsg_device *newch;
+ struct rpmsg_channel_info chinfo;
+ struct device *dev = rpdev->dev.parent;
+ int ret;
+
+#if defined(CONFIG_DYNAMIC_DEBUG)
+ dynamic_hex_dump("NS announcement: ", DUMP_PREFIX_NONE, 16, 1,
+ data, len, true);
+#endif
+
+ if (len != sizeof(*msg)) {
+ dev_err(dev, "malformed ns msg (%d)\n", len);
+ return -EINVAL;
+ }
+
+ /* don't trust the remote processor for null terminating the name */
+ msg->name[RPMSG_NAME_SIZE - 1] = '\0';
+
+ strncpy(chinfo.name, msg->name, sizeof(chinfo.name));
+ chinfo.src = RPMSG_ADDR_ANY;
+ chinfo.dst = rpmsg32_to_cpu(rpdev, msg->addr);
+
+ dev_info(dev, "%sing channel %s addr 0x%x\n",
+ rpmsg32_to_cpu(rpdev, msg->flags) & RPMSG_NS_DESTROY ?
+ "destroy" : "creat", msg->name, chinfo.dst);
+
+ if (rpmsg32_to_cpu(rpdev, msg->flags) & RPMSG_NS_DESTROY) {
+ ret = rpmsg_release_channel(rpdev, &chinfo);
+ if (ret)
+ dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
+ } else {
+ newch = rpmsg_create_channel(rpdev, &chinfo);
+ if (!newch)
+ dev_err(dev, "rpmsg_create_channel failed\n");
+ }
+
+ return 0;
+}
+
+static int rpmsg_ns_probe(struct rpmsg_device *rpdev)
+{
+ struct rpmsg_endpoint *ns_ept;
+ struct rpmsg_channel_info ns_chinfo = {
+ .src = RPMSG_NS_ADDR,
+ .dst = RPMSG_NS_ADDR,
+ .name = "name_service",
+ };
+
+ /*
+ * Create the NS announcement service endpoint associated to the RPMsg
+ * device. The endpoint will be automatically destroyed when the RPMsg
+ * device will be deleted.
+ */
+ ns_ept = rpmsg_create_ept(rpdev, rpmsg_ns_cb, NULL, ns_chinfo);
+ if (!ns_ept) {
+ dev_err(&rpdev->dev, "failed to create the ns ept\n");
+ return -ENOMEM;
+ }
+ rpdev->ept = ns_ept;
+
+ return 0;
+}
+
+static struct rpmsg_driver rpmsg_ns_driver = {
+ .drv.name = KBUILD_MODNAME,
+ .probe = rpmsg_ns_probe,
+};
+
+static int rpmsg_ns_init(void)
+{
+ int ret;
+
+ ret = register_rpmsg_driver(&rpmsg_ns_driver);
+ if (ret < 0)
+ pr_err("%s: Failed to register rpmsg driver\n", __func__);
+
+ return ret;
+}
+postcore_initcall(rpmsg_ns_init);
+
+static void rpmsg_ns_exit(void)
+{
+ unregister_rpmsg_driver(&rpmsg_ns_driver);
+}
+module_exit(rpmsg_ns_exit);
+
+MODULE_DESCRIPTION("Name service announcement rpmsg driver");
+MODULE_AUTHOR("Arnaud Pouliquen <[email protected]>");
+MODULE_ALIAS("rpmsg:" KBUILD_MODNAME);
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 6ec299f7f790..e87d4cf926eb 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -49,7 +49,6 @@
* @endpoints_lock: lock of the endpoints set
* @sendq: wait queue of sending contexts waiting for a tx buffers
* @sleepers: number of senders that are waiting for a tx buffer
- * @ns_ept: the bus's name service endpoint
*
* This structure stores the rpmsg state of a given virtio remote processor
* device (there might be several virtio proc devices for each physical
@@ -68,7 +67,6 @@ struct virtproc_info {
struct mutex endpoints_lock;
wait_queue_head_t sendq;
atomic_t sleepers;
- struct rpmsg_endpoint *ns_ept;
};
/* The feature bitmap for virtio rpmsg */
@@ -815,69 +813,14 @@ static void rpmsg_xmit_done(struct virtqueue *svq)
wake_up_interruptible(&vrp->sendq);
}
-/* invoked when a name service announcement arrives */
-static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
- void *priv, u32 src)
-{
- struct rpmsg_ns_msg *msg = data;
- struct rpmsg_device *newch;
- struct rpmsg_channel_info chinfo;
- struct virtproc_info *vrp = priv;
- struct device *dev = &vrp->vdev->dev;
- bool little_endian = virtio_is_little_endian(vrp->vdev);
- int ret;
-
-#if defined(CONFIG_DYNAMIC_DEBUG)
- dynamic_hex_dump("NS announcement: ", DUMP_PREFIX_NONE, 16, 1,
- data, len, true);
-#endif
-
- if (len != sizeof(*msg)) {
- dev_err(dev, "malformed ns msg (%d)\n", len);
- return -EINVAL;
- }
-
- /*
- * the name service ept does _not_ belong to a real rpmsg channel,
- * and is handled by the rpmsg bus itself.
- * for sanity reasons, make sure a valid rpdev has _not_ sneaked
- * in somehow.
- */
- if (rpdev) {
- dev_err(dev, "anomaly: ns ept has an rpdev handle\n");
- return -EINVAL;
- }
-
- /* don't trust the remote processor for null terminating the name */
- msg->name[RPMSG_NAME_SIZE - 1] = '\0';
-
- strncpy(chinfo.name, msg->name, sizeof(chinfo.name));
- chinfo.src = RPMSG_ADDR_ANY;
- chinfo.dst = __rpmsg32_to_cpu(little_endian, msg->addr);
-
- dev_info(dev, "%sing channel %s addr 0x%x\n",
- __rpmsg32_to_cpu(little_endian, msg->flags) & RPMSG_NS_DESTROY ?
- "destroy" : "creat", msg->name, chinfo.dst);
-
- if (__rpmsg32_to_cpu(little_endian, msg->flags) & RPMSG_NS_DESTROY) {
- ret = rpmsg_unregister_device(&vrp->vdev->dev, &chinfo);
- if (ret)
- dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
- } else {
- newch = __rpmsg_create_channel(vrp, &chinfo);
- if (!newch)
- dev_err(dev, "rpmsg_create_channel failed\n");
- }
-
- return 0;
-}
-
static int rpmsg_probe(struct virtio_device *vdev)
{
vq_callback_t *vq_cbs[] = { rpmsg_recv_done, rpmsg_xmit_done };
static const char * const names[] = { "input", "output" };
struct virtqueue *vqs[2];
struct virtproc_info *vrp;
+ struct virtio_rpmsg_channel *vch;
+ struct rpmsg_device *rpdev_ns;
void *bufs_va;
int err = 0, i;
size_t total_buf_space;
@@ -953,14 +896,26 @@ static int rpmsg_probe(struct virtio_device *vdev)
/* if supported by the remote processor, enable the name service */
if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_NS)) {
- /* a dedicated endpoint handles the name service msgs */
- vrp->ns_ept = __rpmsg_create_ept(vrp, NULL, rpmsg_ns_cb,
- vrp, RPMSG_NS_ADDR);
- if (!vrp->ns_ept) {
- dev_err(&vdev->dev, "failed to create the ns ept\n");
+ vch = kzalloc(sizeof(*vch), GFP_KERNEL);
+ if (!vch) {
err = -ENOMEM;
goto free_coherent;
}
+
+ /* Link the channel to our vrp */
+ vch->vrp = vrp;
+
+ /* Assign public information to the rpmsg_device */
+ rpdev_ns = &vch->rpdev;
+ rpdev_ns->ops = &virtio_rpmsg_ops;
+ rpdev_ns->little_endian = virtio_is_little_endian(vrp->vdev);
+
+ rpdev_ns->dev.parent = &vrp->vdev->dev;
+ rpdev_ns->dev.release = virtio_rpmsg_release_device;
+
+ err = rpmsg_ns_register_device(rpdev_ns);
+ if (err)
+ goto free_coherent;
}
/*
@@ -985,6 +940,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
return 0;
free_coherent:
+ kfree(vch);
dma_free_coherent(vdev->dev.parent, total_buf_space,
bufs_va, vrp->bufs_dma);
vqs_del:
@@ -1013,9 +969,6 @@ static void rpmsg_remove(struct virtio_device *vdev)
if (ret)
dev_warn(&vdev->dev, "can't remove rpmsg device: %d\n", ret);
- if (vrp->ns_ept)
- __rpmsg_destroy_ept(vrp, vrp->ns_ept);
-
idr_destroy(&vrp->endpoints);
vdev->config->del_vqs(vrp->vdev);
diff --git a/include/linux/rpmsg/ns.h b/include/linux/rpmsg/ns.h
index 73ecc91dc26f..a7804edd6d58 100644
--- a/include/linux/rpmsg/ns.h
+++ b/include/linux/rpmsg/ns.h
@@ -4,6 +4,7 @@
#define _LINUX_RPMSG_NS_H
#include <linux/mod_devicetable.h>
+#include <linux/rpmsg.h>
#include <linux/rpmsg/byteorder.h>
#include <linux/types.h>
@@ -39,4 +40,6 @@ enum rpmsg_ns_flags {
/* Address 53 is reserved for advertising remote services */
#define RPMSG_NS_ADDR (53)
+int rpmsg_ns_register_device(struct rpmsg_device *rpdev);
+
#endif
--
2.25.1
Introduce __rpmsg{16|32|64} types along with byte order conversion
functions based on an rpmsg_device operation as a foundation to
make RPMSG modular and transport agnostic.
Suggested-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Arnaud Pouliquen <[email protected]>
---
include/linux/rpmsg.h | 51 ++++++++++++++++++++++++
include/linux/rpmsg/byteorder.h | 67 ++++++++++++++++++++++++++++++++
include/uapi/linux/rpmsg_types.h | 11 ++++++
3 files changed, 129 insertions(+)
create mode 100644 include/linux/rpmsg/byteorder.h
create mode 100644 include/uapi/linux/rpmsg_types.h
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 9fe156d1c018..faf2daff6238 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -17,6 +17,7 @@
#include <linux/kref.h>
#include <linux/mutex.h>
#include <linux/poll.h>
+#include <linux/rpmsg/byteorder.h>
#define RPMSG_ADDR_ANY 0xFFFFFFFF
@@ -46,6 +47,7 @@ struct rpmsg_channel_info {
* @dst: destination address
* @ept: the rpmsg endpoint of this channel
* @announce: if set, rpmsg will announce the creation/removal of this channel
+ * @little_endian: True if transport is using little endian byte representation
*/
struct rpmsg_device {
struct device dev;
@@ -55,6 +57,7 @@ struct rpmsg_device {
u32 dst;
struct rpmsg_endpoint *ept;
bool announce;
+ bool little_endian;
const struct rpmsg_device_ops *ops;
};
@@ -111,6 +114,54 @@ struct rpmsg_driver {
int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
};
+static inline u16 rpmsg16_to_cpu(struct rpmsg_device *rpdev, __rpmsg16 val)
+{
+ if (!rpdev)
+ return __rpmsg16_to_cpu(rpmsg_is_little_endian(), val);
+ else
+ return __rpmsg16_to_cpu(rpdev->little_endian, val);
+}
+
+static inline __rpmsg16 cpu_to_rpmsg16(struct rpmsg_device *rpdev, u16 val)
+{
+ if (!rpdev)
+ return __cpu_to_rpmsg16(rpmsg_is_little_endian(), val);
+ else
+ return __cpu_to_rpmsg16(rpdev->little_endian, val);
+}
+
+static inline u32 rpmsg32_to_cpu(struct rpmsg_device *rpdev, __rpmsg32 val)
+{
+ if (!rpdev)
+ return __rpmsg32_to_cpu(rpmsg_is_little_endian(), val);
+ else
+ return __rpmsg32_to_cpu(rpdev->little_endian, val);
+}
+
+static inline __rpmsg32 cpu_to_rpmsg32(struct rpmsg_device *rpdev, u32 val)
+{
+ if (!rpdev)
+ return __cpu_to_rpmsg32(rpmsg_is_little_endian(), val);
+ else
+ return __cpu_to_rpmsg32(rpdev->little_endian, val);
+}
+
+static inline u64 rpmsg64_to_cpu(struct rpmsg_device *rpdev, __rpmsg64 val)
+{
+ if (!rpdev)
+ return __rpmsg64_to_cpu(rpmsg_is_little_endian(), val);
+ else
+ return __rpmsg64_to_cpu(rpdev->little_endian, val);
+}
+
+static inline __rpmsg64 cpu_to_rpmsg64(struct rpmsg_device *rpdev, u64 val)
+{
+ if (!rpdev)
+ return __cpu_to_rpmsg64(rpmsg_is_little_endian(), val);
+ else
+ return __cpu_to_rpmsg64(rpdev->little_endian, val);
+}
+
#if IS_ENABLED(CONFIG_RPMSG)
int register_rpmsg_device(struct rpmsg_device *dev);
diff --git a/include/linux/rpmsg/byteorder.h b/include/linux/rpmsg/byteorder.h
new file mode 100644
index 000000000000..c0f565dbad6d
--- /dev/null
+++ b/include/linux/rpmsg/byteorder.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Follows implementation found in linux/virtio_byteorder.h
+ */
+#ifndef _LINUX_RPMSG_BYTEORDER_H
+#define _LINUX_RPMSG_BYTEORDER_H
+#include <linux/types.h>
+#include <uapi/linux/rpmsg_types.h>
+
+static inline bool rpmsg_is_little_endian(void)
+{
+#ifdef __LITTLE_ENDIAN
+ return true;
+#else
+ return false;
+#endif
+}
+
+static inline u16 __rpmsg16_to_cpu(bool little_endian, __rpmsg16 val)
+{
+ if (little_endian)
+ return le16_to_cpu((__force __le16)val);
+ else
+ return be16_to_cpu((__force __be16)val);
+}
+
+static inline __rpmsg16 __cpu_to_rpmsg16(bool little_endian, u16 val)
+{
+ if (little_endian)
+ return (__force __rpmsg16)cpu_to_le16(val);
+ else
+ return (__force __rpmsg16)cpu_to_be16(val);
+}
+
+static inline u32 __rpmsg32_to_cpu(bool little_endian, __rpmsg32 val)
+{
+ if (little_endian)
+ return le32_to_cpu((__force __le32)val);
+ else
+ return be32_to_cpu((__force __be32)val);
+}
+
+static inline __rpmsg32 __cpu_to_rpmsg32(bool little_endian, u32 val)
+{
+ if (little_endian)
+ return (__force __rpmsg32)cpu_to_le32(val);
+ else
+ return (__force __rpmsg32)cpu_to_be32(val);
+}
+
+static inline u64 __rpmsg64_to_cpu(bool little_endian, __rpmsg64 val)
+{
+ if (little_endian)
+ return le64_to_cpu((__force __le64)val);
+ else
+ return be64_to_cpu((__force __be64)val);
+}
+
+static inline __rpmsg64 __cpu_to_rpmsg64(bool little_endian, u64 val)
+{
+ if (little_endian)
+ return (__force __rpmsg64)cpu_to_le64(val);
+ else
+ return (__force __rpmsg64)cpu_to_be64(val);
+}
+
+#endif /* _LINUX_RPMSG_BYTEORDER_H */
diff --git a/include/uapi/linux/rpmsg_types.h b/include/uapi/linux/rpmsg_types.h
new file mode 100644
index 000000000000..36e3b9404391
--- /dev/null
+++ b/include/uapi/linux/rpmsg_types.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RPMSG_TYPES_H
+#define _UAPI_LINUX_RPMSG_TYPES_H
+
+#include <linux/types.h>
+
+typedef __u16 __bitwise __rpmsg16;
+typedef __u32 __bitwise __rpmsg32;
+typedef __u64 __bitwise __rpmsg64;
+
+#endif /* _UAPI_LINUX_RPMSG_TYPES_H */
--
2.25.1
From: Arnaud Pouliquen <[email protected]>
Add the channel creation API as a first step to be able to define the
name service announcement as a rpmsg driver independent from the RPMsg
virtio bus.
Signed-off-by: Arnaud Pouliquen <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
---
drivers/rpmsg/rpmsg_core.c | 44 ++++++++++++++++++++++++++++++++++
drivers/rpmsg/rpmsg_internal.h | 10 ++++++++
2 files changed, 54 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index 91de940896e3..e5daee4f9373 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -20,6 +20,50 @@
#include "rpmsg_internal.h"
+/**
+ * rpmsg_create_channel() - create a new rpmsg channel
+ * using its name and address info.
+ * @rpdev: rpmsg device
+ * @chinfo: channel_info to bind
+ *
+ * Returns a pointer to the new rpmsg device on success, or NULL on error.
+ */
+struct rpmsg_device *rpmsg_create_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ if (WARN_ON(!rpdev))
+ return NULL;
+ if (!rpdev->ops || !rpdev->ops->create_channel) {
+ dev_err(&rpdev->dev, "no create_channel ops found\n");
+ return NULL;
+ }
+
+ return rpdev->ops->create_channel(rpdev, chinfo);
+}
+EXPORT_SYMBOL(rpmsg_create_channel);
+
+/**
+ * rpmsg_release_channel() - release a rpmsg channel
+ * using its name and address info.
+ * @rpdev: rpmsg device
+ * @chinfo: channel_info to bind
+ *
+ * Returns 0 on success or an appropriate error value.
+ */
+int rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ if (WARN_ON(!rpdev))
+ return -EINVAL;
+ if (!rpdev->ops || !rpdev->ops->release_channel) {
+ dev_err(&rpdev->dev, "no release_channel ops found\n");
+ return -ENXIO;
+ }
+
+ return rpdev->ops->release_channel(rpdev, chinfo);
+}
+EXPORT_SYMBOL(rpmsg_release_channel);
+
/**
* rpmsg_create_ept() - create a new rpmsg_endpoint
* @rpdev: rpmsg channel device
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 3fc83cd50e98..f1de73e0f2d6 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -20,6 +20,8 @@
/**
* struct rpmsg_device_ops - indirection table for the rpmsg_device operations
+ * @create_channel: create backend-specific channel, optional
+ * @release_channel: release backend-specific channel, optional
* @create_ept: create backend-specific endpoint, required
* @announce_create: announce presence of new channel, optional
* @announce_destroy: announce destruction of channel, optional
@@ -29,6 +31,10 @@
* advertise new channels implicitly by creating the endpoints.
*/
struct rpmsg_device_ops {
+ struct rpmsg_device *(*create_channel)(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
+ int (*release_channel)(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev,
rpmsg_rx_cb_t cb, void *priv,
struct rpmsg_channel_info chinfo);
@@ -75,6 +81,10 @@ int rpmsg_unregister_device(struct device *parent,
struct device *rpmsg_find_device(struct device *parent,
struct rpmsg_channel_info *chinfo);
+struct rpmsg_device *rpmsg_create_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
+int rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
/**
* rpmsg_chrdev_register_device() - register chrdev device based on rpdev
* @rpdev: prepared rpdev to be used for creating endpoints
--
2.25.1
From: Arnaud Pouliquen <[email protected]>
Implement the create and release of the RPMsg channel
for the RPMsg virtio bus.
Signed-off-by: Arnaud Pouliquen <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 2253936593c5..6ec299f7f790 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -151,6 +151,8 @@ static int virtio_rpmsg_trysendto(struct rpmsg_endpoint *ept, void *data,
int len, u32 dst);
static int virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src,
u32 dst, void *data, int len);
+static struct rpmsg_device *__rpmsg_create_channel(struct virtproc_info *vrp,
+ struct rpmsg_channel_info *chinfo);
static const struct rpmsg_endpoint_ops virtio_endpoint_ops = {
.destroy_ept = virtio_rpmsg_destroy_ept,
@@ -255,6 +257,24 @@ static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp,
return NULL;
}
+static struct rpmsg_device *virtio_rpmsg_create_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
+ struct virtproc_info *vrp = vch->vrp;
+
+ return __rpmsg_create_channel(vrp, chinfo);
+}
+
+static int virtio_rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
+ struct virtproc_info *vrp = vch->vrp;
+
+ return rpmsg_unregister_device(&vrp->vdev->dev, chinfo);
+}
+
static struct rpmsg_endpoint *virtio_rpmsg_create_ept(struct rpmsg_device *rpdev,
rpmsg_rx_cb_t cb,
void *priv,
@@ -347,6 +367,8 @@ static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
}
static const struct rpmsg_device_ops virtio_rpmsg_ops = {
+ .create_channel = virtio_rpmsg_create_channel,
+ .release_channel = virtio_rpmsg_release_channel,
.create_ept = virtio_rpmsg_create_ept,
.announce_create = virtio_rpmsg_announce_create,
.announce_destroy = virtio_rpmsg_announce_destroy,
--
2.25.1
From: Arnaud Pouliquen <[email protected]>
Rename the internal function as it is internal, and as
the name will be used in rpmsg_core.
Signed-off-by: Arnaud Pouliquen <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 20d0cf909bea..2253936593c5 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -365,8 +365,8 @@ static void virtio_rpmsg_release_device(struct device *dev)
* this function will be used to create both static and dynamic
* channels.
*/
-static struct rpmsg_device *rpmsg_create_channel(struct virtproc_info *vrp,
- struct rpmsg_channel_info *chinfo)
+static struct rpmsg_device *__rpmsg_create_channel(struct virtproc_info *vrp,
+ struct rpmsg_channel_info *chinfo)
{
struct virtio_rpmsg_channel *vch;
struct rpmsg_device *rpdev;
@@ -842,7 +842,7 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
if (ret)
dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
} else {
- newch = rpmsg_create_channel(vrp, &chinfo);
+ newch = __rpmsg_create_channel(vrp, &chinfo);
if (!newch)
dev_err(dev, "rpmsg_create_channel failed\n");
}
--
2.25.1
Hi Mathieu,
Thanks for bringing all the stuff together and for polishing it!
For the entire series:
Tested-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Thanks
Guennadi
On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
> This revision addresses comments received from the previous revision,
> i.e V6. Please see details below.
>
> It starts by making the RPMSG protocol transport agnostic by
> moving the headers it uses to generic types and using those in the
> current implementation. From there it re-uses the work that Arnaud
> published[1] to make the name service modular.
>
> Tested on stm32mp157 with the RPMSG client sample application. Applies
> cleanly on rpmsg-next.
>
> Thanks,
> Mathieu
>
> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
>
> -------
> New for V7:
> - Fixed error path in rpmsg_probe() as reported by Guennadi
>
> Arnaud Pouliquen (4):
> rpmsg: virtio: Rename rpmsg_create_channel
> rpmsg: core: Add channel creation internal API
> rpmsg: virtio: Add rpmsg channel device ops
> rpmsg: Turn name service into a stand alone driver
>
> Mathieu Poirier (4):
> rpmsg: Introduce __rpmsg{16|32|64} types
> rpmsg: virtio: Move from virtio to rpmsg byte conversion
> rpmsg: Move structure rpmsg_ns_msg to header file
> rpmsg: Make rpmsg_{register|unregister}_device() public
>
> drivers/rpmsg/Kconfig | 9 ++
> drivers/rpmsg/Makefile | 1 +
> drivers/rpmsg/rpmsg_core.c | 44 ++++++++
> drivers/rpmsg/rpmsg_internal.h | 14 ++-
> drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
> drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
> include/linux/rpmsg.h | 63 ++++++++++-
> include/linux/rpmsg/byteorder.h | 67 +++++++++++
> include/linux/rpmsg/ns.h | 45 ++++++++
> include/uapi/linux/rpmsg_types.h | 11 ++
> 10 files changed, 439 insertions(+), 127 deletions(-)
> create mode 100644 drivers/rpmsg/rpmsg_ns.c
> create mode 100644 include/linux/rpmsg/byteorder.h
> create mode 100644 include/linux/rpmsg/ns.h
> create mode 100644 include/uapi/linux/rpmsg_types.h
>
> --
> 2.25.1
>
Hi Mathieu,
I'd like to resume reviewing and begin upstreaming of the next steps of
my Audio DSP Virtualisation work, based on this your patch set. How
confident are we that it's going to be upstreamed in its present form?
What's the plan to push it to "next?"
Thanks
Guennadi
On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote:
> Hi Mathieu,
>
> Thanks for bringing all the stuff together and for polishing it!
>
> For the entire series:
>
> Tested-by: Guennadi Liakhovetski <[email protected]>
> Reviewed-by: Guennadi Liakhovetski <[email protected]>
>
> Thanks
> Guennadi
>
> On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
> > This revision addresses comments received from the previous revision,
> > i.e V6. Please see details below.
> >
> > It starts by making the RPMSG protocol transport agnostic by
> > moving the headers it uses to generic types and using those in the
> > current implementation. From there it re-uses the work that Arnaud
> > published[1] to make the name service modular.
> >
> > Tested on stm32mp157 with the RPMSG client sample application. Applies
> > cleanly on rpmsg-next.
> >
> > Thanks,
> > Mathieu
> >
> > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
> >
> > -------
> > New for V7:
> > - Fixed error path in rpmsg_probe() as reported by Guennadi
> >
> > Arnaud Pouliquen (4):
> > rpmsg: virtio: Rename rpmsg_create_channel
> > rpmsg: core: Add channel creation internal API
> > rpmsg: virtio: Add rpmsg channel device ops
> > rpmsg: Turn name service into a stand alone driver
> >
> > Mathieu Poirier (4):
> > rpmsg: Introduce __rpmsg{16|32|64} types
> > rpmsg: virtio: Move from virtio to rpmsg byte conversion
> > rpmsg: Move structure rpmsg_ns_msg to header file
> > rpmsg: Make rpmsg_{register|unregister}_device() public
> >
> > drivers/rpmsg/Kconfig | 9 ++
> > drivers/rpmsg/Makefile | 1 +
> > drivers/rpmsg/rpmsg_core.c | 44 ++++++++
> > drivers/rpmsg/rpmsg_internal.h | 14 ++-
> > drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
> > drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
> > include/linux/rpmsg.h | 63 ++++++++++-
> > include/linux/rpmsg/byteorder.h | 67 +++++++++++
> > include/linux/rpmsg/ns.h | 45 ++++++++
> > include/uapi/linux/rpmsg_types.h | 11 ++
> > 10 files changed, 439 insertions(+), 127 deletions(-)
> > create mode 100644 drivers/rpmsg/rpmsg_ns.c
> > create mode 100644 include/linux/rpmsg/byteorder.h
> > create mode 100644 include/linux/rpmsg/ns.h
> > create mode 100644 include/uapi/linux/rpmsg_types.h
> >
> > --
> > 2.25.1
> >
Good day,
On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote:
> Hi Mathieu,
>
> I'd like to resume reviewing and begin upstreaming of the next steps of
> my Audio DSP Virtualisation work, based on this your patch set. How
I'm all for it too.
> confident are we that it's going to be upstreamed in its present form?
> What's the plan to push it to "next?"
>
I thought we were pretty unanimous that something like what Kishon did was the
way to go.
> Thanks
> Guennadi
>
> On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> >
> > Thanks for bringing all the stuff together and for polishing it!
> >
> > For the entire series:
> >
> > Tested-by: Guennadi Liakhovetski <[email protected]>
> > Reviewed-by: Guennadi Liakhovetski <[email protected]>
> >
> > Thanks
> > Guennadi
> >
> > On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
> > > This revision addresses comments received from the previous revision,
> > > i.e V6. Please see details below.
> > >
> > > It starts by making the RPMSG protocol transport agnostic by
> > > moving the headers it uses to generic types and using those in the
> > > current implementation. From there it re-uses the work that Arnaud
> > > published[1] to make the name service modular.
> > >
> > > Tested on stm32mp157 with the RPMSG client sample application. Applies
> > > cleanly on rpmsg-next.
> > >
> > > Thanks,
> > > Mathieu
> > >
> > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
> > >
> > > -------
> > > New for V7:
> > > - Fixed error path in rpmsg_probe() as reported by Guennadi
> > >
> > > Arnaud Pouliquen (4):
> > > rpmsg: virtio: Rename rpmsg_create_channel
> > > rpmsg: core: Add channel creation internal API
> > > rpmsg: virtio: Add rpmsg channel device ops
> > > rpmsg: Turn name service into a stand alone driver
> > >
> > > Mathieu Poirier (4):
> > > rpmsg: Introduce __rpmsg{16|32|64} types
> > > rpmsg: virtio: Move from virtio to rpmsg byte conversion
> > > rpmsg: Move structure rpmsg_ns_msg to header file
> > > rpmsg: Make rpmsg_{register|unregister}_device() public
> > >
> > > drivers/rpmsg/Kconfig | 9 ++
> > > drivers/rpmsg/Makefile | 1 +
> > > drivers/rpmsg/rpmsg_core.c | 44 ++++++++
> > > drivers/rpmsg/rpmsg_internal.h | 14 ++-
> > > drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
> > > drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
> > > include/linux/rpmsg.h | 63 ++++++++++-
> > > include/linux/rpmsg/byteorder.h | 67 +++++++++++
> > > include/linux/rpmsg/ns.h | 45 ++++++++
> > > include/uapi/linux/rpmsg_types.h | 11 ++
> > > 10 files changed, 439 insertions(+), 127 deletions(-)
> > > create mode 100644 drivers/rpmsg/rpmsg_ns.c
> > > create mode 100644 include/linux/rpmsg/byteorder.h
> > > create mode 100644 include/linux/rpmsg/ns.h
> > > create mode 100644 include/uapi/linux/rpmsg_types.h
> > >
> > > --
> > > 2.25.1
> > >
(adding vhost maintainers and the author of [1])
Hi,
I'm working on an Audio DSP virtualisation solution [2] and the next
step in its upstreaming should be an RPMsg vhost implementation, based
on [3], which contains a simple addition to the current library-style
vhost API. Later in [1] a different approach has been presented,
converting the vhost framework to a proper bus-type and device driver.
Therefore my questions:
1. if the latter approach is prefered, should we expect follow up
versions of [1] and their upstreaming?
2. judging by the size and complexity of [1] would it maybe be
preferable to first extract a minimum patch set just to add vhost
rpmsg? Looking at the patch set it should be doable and not too
difficult? Kishon, would it be something you could submit?
3. or would it be preferable to keep vhost in its present form, use
[3] for rpmsg support and re-implement [1] based on a different
vhost / vringh approach?
Thanks
Guennadi
[1] https://www.spinics.net/lists/kvm/msg219632.html
[2] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-April/003766.html
[3] https://www.spinics.net/lists/linux-virtualization/msg43359.html
On Wed, Dec 02, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote:
> Good day,
>
> On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> >
> > I'd like to resume reviewing and begin upstreaming of the next steps of
> > my Audio DSP Virtualisation work, based on this your patch set. How
>
> I'm all for it too.
>
> > confident are we that it's going to be upstreamed in its present form?
> > What's the plan to push it to "next?"
> >
>
> I thought we were pretty unanimous that something like what Kishon did was the
> way to go.
>
> > Thanks
> > Guennadi
> >
> > On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote:
> > > Hi Mathieu,
> > >
> > > Thanks for bringing all the stuff together and for polishing it!
> > >
> > > For the entire series:
> > >
> > > Tested-by: Guennadi Liakhovetski <[email protected]>
> > > Reviewed-by: Guennadi Liakhovetski <[email protected]>
> > >
> > > Thanks
> > > Guennadi
> > >
> > > On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
> > > > This revision addresses comments received from the previous revision,
> > > > i.e V6. Please see details below.
> > > >
> > > > It starts by making the RPMSG protocol transport agnostic by
> > > > moving the headers it uses to generic types and using those in the
> > > > current implementation. From there it re-uses the work that Arnaud
> > > > published[1] to make the name service modular.
> > > >
> > > > Tested on stm32mp157 with the RPMSG client sample application. Applies
> > > > cleanly on rpmsg-next.
> > > >
> > > > Thanks,
> > > > Mathieu
> > > >
> > > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
> > > >
> > > > -------
> > > > New for V7:
> > > > - Fixed error path in rpmsg_probe() as reported by Guennadi
> > > >
> > > > Arnaud Pouliquen (4):
> > > > rpmsg: virtio: Rename rpmsg_create_channel
> > > > rpmsg: core: Add channel creation internal API
> > > > rpmsg: virtio: Add rpmsg channel device ops
> > > > rpmsg: Turn name service into a stand alone driver
> > > >
> > > > Mathieu Poirier (4):
> > > > rpmsg: Introduce __rpmsg{16|32|64} types
> > > > rpmsg: virtio: Move from virtio to rpmsg byte conversion
> > > > rpmsg: Move structure rpmsg_ns_msg to header file
> > > > rpmsg: Make rpmsg_{register|unregister}_device() public
> > > >
> > > > drivers/rpmsg/Kconfig | 9 ++
> > > > drivers/rpmsg/Makefile | 1 +
> > > > drivers/rpmsg/rpmsg_core.c | 44 ++++++++
> > > > drivers/rpmsg/rpmsg_internal.h | 14 ++-
> > > > drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
> > > > drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
> > > > include/linux/rpmsg.h | 63 ++++++++++-
> > > > include/linux/rpmsg/byteorder.h | 67 +++++++++++
> > > > include/linux/rpmsg/ns.h | 45 ++++++++
> > > > include/uapi/linux/rpmsg_types.h | 11 ++
> > > > 10 files changed, 439 insertions(+), 127 deletions(-)
> > > > create mode 100644 drivers/rpmsg/rpmsg_ns.c
> > > > create mode 100644 include/linux/rpmsg/byteorder.h
> > > > create mode 100644 include/linux/rpmsg/ns.h
> > > > create mode 100644 include/uapi/linux/rpmsg_types.h
> > > >
> > > > --
> > > > 2.25.1
> > > >
I am adding Vincent Whitchurch and the virtualization mailing list...
On Thu, 3 Dec 2020 at 13:42, Guennadi Liakhovetski
<[email protected]> wrote:
>
> (adding vhost maintainers and the author of [1])
>
> Hi,
>
> I'm working on an Audio DSP virtualisation solution [2] and the next
> step in its upstreaming should be an RPMsg vhost implementation, based
> on [3], which contains a simple addition to the current library-style
> vhost API. Later in [1] a different approach has been presented,
> converting the vhost framework to a proper bus-type and device driver.
> Therefore my questions:
>
> 1. if the latter approach is prefered, should we expect follow up
> versions of [1] and their upstreaming?
> 2. judging by the size and complexity of [1] would it maybe be
> preferable to first extract a minimum patch set just to add vhost
> rpmsg? Looking at the patch set it should be doable and not too
> difficult? Kishon, would it be something you could submit?
To me that is the best approach. It might be best for you to do the
work and credit Kishon where needed.
> 3. or would it be preferable to keep vhost in its present form, use
> [3] for rpmsg support and re-implement [1] based on a different
> vhost / vringh approach?
>
> Thanks
> Guennadi
>
> [1] https://www.spinics.net/lists/kvm/msg219632.html
> [2] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-April/003766.html
> [3] https://www.spinics.net/lists/linux-virtualization/msg43359.html
>
> On Wed, Dec 02, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote:
> > Good day,
> >
> > On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote:
> > > Hi Mathieu,
> > >
> > > I'd like to resume reviewing and begin upstreaming of the next steps of
> > > my Audio DSP Virtualisation work, based on this your patch set. How
> >
> > I'm all for it too.
> >
> > > confident are we that it's going to be upstreamed in its present form?
> > > What's the plan to push it to "next?"
> > >
> >
> > I thought we were pretty unanimous that something like what Kishon did was the
> > way to go.
> >
> > > Thanks
> > > Guennadi
> > >
> > > On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote:
> > > > Hi Mathieu,
> > > >
> > > > Thanks for bringing all the stuff together and for polishing it!
> > > >
> > > > For the entire series:
> > > >
> > > > Tested-by: Guennadi Liakhovetski <[email protected]>
> > > > Reviewed-by: Guennadi Liakhovetski <[email protected]>
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > > On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
> > > > > This revision addresses comments received from the previous revision,
> > > > > i.e V6. Please see details below.
> > > > >
> > > > > It starts by making the RPMSG protocol transport agnostic by
> > > > > moving the headers it uses to generic types and using those in the
> > > > > current implementation. From there it re-uses the work that Arnaud
> > > > > published[1] to make the name service modular.
> > > > >
> > > > > Tested on stm32mp157 with the RPMSG client sample application. Applies
> > > > > cleanly on rpmsg-next.
> > > > >
> > > > > Thanks,
> > > > > Mathieu
> > > > >
> > > > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
> > > > >
> > > > > -------
> > > > > New for V7:
> > > > > - Fixed error path in rpmsg_probe() as reported by Guennadi
> > > > >
> > > > > Arnaud Pouliquen (4):
> > > > > rpmsg: virtio: Rename rpmsg_create_channel
> > > > > rpmsg: core: Add channel creation internal API
> > > > > rpmsg: virtio: Add rpmsg channel device ops
> > > > > rpmsg: Turn name service into a stand alone driver
> > > > >
> > > > > Mathieu Poirier (4):
> > > > > rpmsg: Introduce __rpmsg{16|32|64} types
> > > > > rpmsg: virtio: Move from virtio to rpmsg byte conversion
> > > > > rpmsg: Move structure rpmsg_ns_msg to header file
> > > > > rpmsg: Make rpmsg_{register|unregister}_device() public
> > > > >
> > > > > drivers/rpmsg/Kconfig | 9 ++
> > > > > drivers/rpmsg/Makefile | 1 +
> > > > > drivers/rpmsg/rpmsg_core.c | 44 ++++++++
> > > > > drivers/rpmsg/rpmsg_internal.h | 14 ++-
> > > > > drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
> > > > > drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
> > > > > include/linux/rpmsg.h | 63 ++++++++++-
> > > > > include/linux/rpmsg/byteorder.h | 67 +++++++++++
> > > > > include/linux/rpmsg/ns.h | 45 ++++++++
> > > > > include/uapi/linux/rpmsg_types.h | 11 ++
> > > > > 10 files changed, 439 insertions(+), 127 deletions(-)
> > > > > create mode 100644 drivers/rpmsg/rpmsg_ns.c
> > > > > create mode 100644 include/linux/rpmsg/byteorder.h
> > > > > create mode 100644 include/linux/rpmsg/ns.h
> > > > > create mode 100644 include/uapi/linux/rpmsg_types.h
> > > > >
> > > > > --
> > > > > 2.25.1
> > > > >
+Lorenzo, Bjorn, Rob
Hi Guennadi,
On 04/12/20 11:21 pm, Mathieu Poirier wrote:
> I am adding Vincent Whitchurch and the virtualization mailing list...
>
> On Thu, 3 Dec 2020 at 13:42, Guennadi Liakhovetski
> <[email protected]> wrote:
>>
>> (adding vhost maintainers and the author of [1])
>>
>> Hi,
>>
>> I'm working on an Audio DSP virtualisation solution [2] and the next
>> step in its upstreaming should be an RPMsg vhost implementation, based
>> on [3], which contains a simple addition to the current library-style
>> vhost API. Later in [1] a different approach has been presented,
>> converting the vhost framework to a proper bus-type and device driver.
>> Therefore my questions:
>>
>> 1. if the latter approach is prefered, should we expect follow up
>> versions of [1] and their upstreaming?
>> 2. judging by the size and complexity of [1] would it maybe be
>> preferable to first extract a minimum patch set just to add vhost
>> rpmsg? Looking at the patch set it should be doable and not too
>> difficult? Kishon, would it be something you could submit?
>
> To me that is the best approach. It might be best for you to do the
> work and credit Kishon where needed.
Yeah, my focus right now is to get my NTB patch series upstreamed [A],
So I might not be able to get to this any sooner. As Mathieu suggested,
I recommend you to pick the generic parts of my series that doesn't
involve PCI or NTB or VHOST MMIO.
The following patches in my series should get the generic vhost
infrastructure part up.
0001-vhost-Make-_feature_-bits-a-property-of-vhost-device.patch
0002-vhost-Introduce-standard-Linux-driver-model-in-VHOST.patch
0003-vhost-Add-ops-for-the-VHOST-driver-to-configure-VHOS.patch
0006-vhost-Introduce-configfs-entry-for-configuring-VHOST.patch
0008-rpmsg-virtio_rpmsg_bus-Disable-receive-virtqueue-cal.patch
0009-rpmsg-Introduce-configfs-entry-for-configuring-rpmsg.patch
0010-rpmsg-virtio_rpmsg_bus-Add-Address-Service-Notificat.patch
0011-rpmsg-virtio_rpmsg_bus-Move-generic-rpmsg-structure-.patch
0014-rpmsg-Add-VHOST-based-remote-processor-messaging-bus.patch
0015-samples-rpmsg-Setup-delayed-work-to-send-message.patch
0016-samples-rpmsg-Wait-for-address-to-be-bound-to-rpdev-.patch
0017-rpmsg.txt-Add-Documentation-to-configure-rpmsg-using.patch
Let me know if you have any questions or need further clarifications.
Thank you for working on this.
Best Regards,
Kishon
[A] -> http://lore.kernel.org/r/[email protected]
>
>> 3. or would it be preferable to keep vhost in its present form, use
>> [3] for rpmsg support and re-implement [1] based on a different
>> vhost / vringh approach?
>>
>> Thanks
>> Guennadi
>>
>> [1] https://www.spinics.net/lists/kvm/msg219632.html
>> [2] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-April/003766.html
>> [3] https://www.spinics.net/lists/linux-virtualization/msg43359.html
>>
>> On Wed, Dec 02, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote:
>>> Good day,
>>>
>>> On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote:
>>>> Hi Mathieu,
>>>>
>>>> I'd like to resume reviewing and begin upstreaming of the next steps of
>>>> my Audio DSP Virtualisation work, based on this your patch set. How
>>>
>>> I'm all for it too.
>>>
>>>> confident are we that it's going to be upstreamed in its present form?
>>>> What's the plan to push it to "next?"
>>>>
>>>
>>> I thought we were pretty unanimous that something like what Kishon did was the
>>> way to go.
>>>
>>>> Thanks
>>>> Guennadi
>>>>
>>>> On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote:
>>>>> Hi Mathieu,
>>>>>
>>>>> Thanks for bringing all the stuff together and for polishing it!
>>>>>
>>>>> For the entire series:
>>>>>
>>>>> Tested-by: Guennadi Liakhovetski <[email protected]>
>>>>> Reviewed-by: Guennadi Liakhovetski <[email protected]>
>>>>>
>>>>> Thanks
>>>>> Guennadi
>>>>>
>>>>> On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote:
>>>>>> This revision addresses comments received from the previous revision,
>>>>>> i.e V6. Please see details below.
>>>>>>
>>>>>> It starts by making the RPMSG protocol transport agnostic by
>>>>>> moving the headers it uses to generic types and using those in the
>>>>>> current implementation. From there it re-uses the work that Arnaud
>>>>>> published[1] to make the name service modular.
>>>>>>
>>>>>> Tested on stm32mp157 with the RPMSG client sample application. Applies
>>>>>> cleanly on rpmsg-next.
>>>>>>
>>>>>> Thanks,
>>>>>> Mathieu
>>>>>>
>>>>>> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335
>>>>>>
>>>>>> -------
>>>>>> New for V7:
>>>>>> - Fixed error path in rpmsg_probe() as reported by Guennadi
>>>>>>
>>>>>> Arnaud Pouliquen (4):
>>>>>> rpmsg: virtio: Rename rpmsg_create_channel
>>>>>> rpmsg: core: Add channel creation internal API
>>>>>> rpmsg: virtio: Add rpmsg channel device ops
>>>>>> rpmsg: Turn name service into a stand alone driver
>>>>>>
>>>>>> Mathieu Poirier (4):
>>>>>> rpmsg: Introduce __rpmsg{16|32|64} types
>>>>>> rpmsg: virtio: Move from virtio to rpmsg byte conversion
>>>>>> rpmsg: Move structure rpmsg_ns_msg to header file
>>>>>> rpmsg: Make rpmsg_{register|unregister}_device() public
>>>>>>
>>>>>> drivers/rpmsg/Kconfig | 9 ++
>>>>>> drivers/rpmsg/Makefile | 1 +
>>>>>> drivers/rpmsg/rpmsg_core.c | 44 ++++++++
>>>>>> drivers/rpmsg/rpmsg_internal.h | 14 ++-
>>>>>> drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++
>>>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++--------------------
>>>>>> include/linux/rpmsg.h | 63 ++++++++++-
>>>>>> include/linux/rpmsg/byteorder.h | 67 +++++++++++
>>>>>> include/linux/rpmsg/ns.h | 45 ++++++++
>>>>>> include/uapi/linux/rpmsg_types.h | 11 ++
>>>>>> 10 files changed, 439 insertions(+), 127 deletions(-)
>>>>>> create mode 100644 drivers/rpmsg/rpmsg_ns.c
>>>>>> create mode 100644 include/linux/rpmsg/byteorder.h
>>>>>> create mode 100644 include/linux/rpmsg/ns.h
>>>>>> create mode 100644 include/uapi/linux/rpmsg_types.h
>>>>>>
>>>>>> --
>>>>>> 2.25.1
>>>>>>