From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 6/9] rpmsg: virtio: use rpmsg ns device for the ns announcement
Date: Mon, 24 Aug 2020 16:48:53 -0600 [thread overview]
Message-ID: <20200824224853.GE3938186@xps15> (raw)
In-Reply-To: <20200731114732.12815-7-arnaud.pouliquen@st.com>
On Fri, Jul 31, 2020 at 01:47:29PM +0200, Arnaud Pouliquen wrote:
> As generic NS driver is available, rely on it for NS management instead of
> managing it in RPMsg virtio bus.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> ---
> drivers/rpmsg/Kconfig | 1 +
> drivers/rpmsg/virtio_rpmsg_bus.c | 86 ++++++++------------------------
> 2 files changed, 21 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index 140faa975ea1..0143c9864c45 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -71,5 +71,6 @@ config RPMSG_VIRTIO
> depends on HAS_DMA
> select RPMSG
> select VIRTIO
> + select RPMSG_NS
>
> endmenu
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> index b2927661868c..f771fdae150e 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -48,7 +48,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
> @@ -67,7 +66,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 */
> @@ -841,68 +839,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;
> - 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 = virtio32_to_cpu(vrp->vdev, msg->addr);
> -
> - dev_info(dev, "%sing channel %s addr 0x%x\n",
> - virtio32_to_cpu(vrp->vdev, msg->flags) & RPMSG_NS_DESTROY ?
> - "destroy" : "creat", msg->name, chinfo.dst);
> -
> - if (virtio32_to_cpu(vrp->vdev, 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;
> @@ -978,14 +922,27 @@ 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->dev.parent = &vrp->vdev->dev;
> + rpdev_ns->dev.release = virtio_rpmsg_release_device;
> +
> + err = rpmsg_ns_register_device(rpdev_ns);
> + if (err) {
> + kfree(vch);
> + goto free_coherent;
> + }
This patch doesn't apply to Bjorn's rproc-next anymore - would you mind
rebasing?
> }
>
> /*
> @@ -1038,9 +995,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);
> --
> 2.17.1
>
next prev parent reply other threads:[~2020-08-24 22:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 11:47 [PATCH 0/9] introduce name service announcement rpmsg driver Arnaud Pouliquen
2020-07-31 11:47 ` [PATCH 1/9] rpmsg: virtio: rename rpmsg_create_channel Arnaud Pouliquen
2020-07-31 11:47 ` [PATCH 2/9] rpmsg: core: add channel creation internal API Arnaud Pouliquen
2020-08-24 22:44 ` Mathieu Poirier
2020-07-31 11:47 ` [PATCH 3/9] rpmsg: virtio: add rpmsg channel device ops Arnaud Pouliquen
2020-07-31 11:47 ` [PATCH 4/9] rpmsg: define the name service announcement as reserved address Arnaud Pouliquen
2020-07-31 11:47 ` [PATCH 5/9] rpmsg: introduce reserved rpmsg driver for ns announcement Arnaud Pouliquen
2020-08-05 9:05 ` kernel test robot
2020-08-05 9:05 ` kernel test robot
2020-08-24 22:47 ` Mathieu Poirier
2020-08-25 11:57 ` Arnaud POULIQUEN
2020-08-25 14:36 ` Mathieu Poirier
2020-07-31 11:47 ` [PATCH 6/9] rpmsg: virtio: use rpmsg ns device for the " Arnaud Pouliquen
2020-08-24 22:48 ` Mathieu Poirier [this message]
2020-08-25 12:02 ` Arnaud POULIQUEN
2020-07-31 11:47 ` [PATCH 7/9] rpmsg: ns: add name service announcement service Arnaud Pouliquen
2020-07-31 11:47 ` [PATCH 8/9] rpmsg: virtio: use rpmsg_ns driver to manage ns announcement Arnaud Pouliquen
2020-08-25 16:54 ` Mathieu Poirier
2020-08-26 7:42 ` Arnaud POULIQUEN
2020-08-26 22:10 ` Mathieu Poirier
2020-08-27 7:03 ` Arnaud POULIQUEN
2020-07-31 11:47 ` [PATCH 9/9] rpmsg: ns: name service announcement endianness Arnaud Pouliquen
2020-08-24 23:04 ` Mathieu Poirier
2020-08-20 22:32 ` [PATCH 0/9] introduce name service announcement rpmsg driver Mathieu Poirier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200824224853.GE3938186@xps15 \
--to=mathieu.poirier@linaro.org \
--cc=arnaud.pouliquen@st.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=ohad@wizery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.