From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
Rob Herring <robh@kernel.org>, Christoph Hellwig <hch@lst.de>,
Stefano Stabellini <stefanos@xilinx.com>,
Bruce Ashfield <bruce.ashfield@xilinx.com>
Subject: Re: [RFC PATCH v3 1/4] remoteproc: core: Introduce virtio device add/remove functions
Date: Fri, 4 Mar 2022 11:29:44 -0700 [thread overview]
Message-ID: <20220304182944.GA1660165@p14s> (raw)
In-Reply-To: <20220126162405.1131323-2-arnaud.pouliquen@foss.st.com>
Good morning,
It took longer than expected to review this set as I wanted to make sure the
unwind path was handled properly.
On Wed, Jan 26, 2022 at 05:24:02PM +0100, Arnaud Pouliquen wrote:
> In preparation of the migration of the management of rvdev in
> remoteproc_virtio.c, this patch spins off new functions to manage the
> remoteproc virtio device.
> - rproc_rvdev_add_device
> - rproc_rvdev_remove_device
>
> The rproc_rvdev_add_device and rproc_rvdev_remove_device will be
> moved to remoteproc_virtio.c.
>
> The rproc_vdev_data structure is introduced to provide information for
> the rvdev creation. This structure allows to manage the rvdev and vrings
> allocation in the rproc_rvdev_add_device function.
> Then the rproc_vdev_data structure will be reused in a next patch as
> platform data structure when the rvdev will rely on a platform device.
>
The last sentence is not needed, please remove.
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> ---
> update vs previous revision:
> - rework rproc_rvdev_add_device function to better manage error cases
> - introduce rproc_vdev_data struct
> - allocate rvdev in rproc_rvdev_add_device
> ---
> drivers/remoteproc/remoteproc_core.c | 164 ++++++++++++++++-----------
> 1 file changed, 98 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 69f51acf235e..83ff44a6a4db 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -66,6 +66,13 @@ static const char * const rproc_crash_names[] = {
> [RPROC_FATAL_ERROR] = "fatal error",
> };
>
> +struct rproc_vdev_data {
> + struct fw_rsc_vdev *rsc;
> + u32 rsc_offset;
> + unsigned int id;
> + unsigned int index;
> +};
Here this structure is introduced without documentation and in patch 3/4 it is
moved to remoteproc_internal.h where documentation is added. Please added there
(with documentation) in the first place. That way it doesn't have to be moved
again.
> +
> /* translate rproc_crash_type to string */
> static const char *rproc_crash_to_string(enum rproc_crash_type type)
> {
> @@ -484,74 +491,23 @@ static int copy_dma_range_map(struct device *to, struct device *from)
> return 0;
> }
>
> -/**
> - * rproc_handle_vdev() - handle a vdev fw resource
> - * @rproc: the remote processor
> - * @ptr: the vring resource descriptor
> - * @offset: offset of the resource entry
> - * @avail: size of available data (for sanity checking the image)
> - *
> - * This resource entry requests the host to statically register a virtio
> - * device (vdev), and setup everything needed to support it. It contains
> - * everything needed to make it possible: the virtio device id, virtio
> - * device features, vrings information, virtio config space, etc...
> - *
> - * Before registering the vdev, the vrings are allocated from non-cacheable
> - * physically contiguous memory. Currently we only support two vrings per
> - * remote processor (temporary limitation). We might also want to consider
> - * doing the vring allocation only later when ->find_vqs() is invoked, and
> - * then release them upon ->del_vqs().
> - *
> - * Note: @da is currently not really handled correctly: we dynamically
> - * allocate it using the DMA API, ignoring requested hard coded addresses,
> - * and we don't take care of any required IOMMU programming. This is all
> - * going to be taken care of when the generic iommu-based DMA API will be
> - * merged. Meanwhile, statically-addressed iommu-based firmware images should
> - * use RSC_DEVMEM resource entries to map their required @da to the physical
> - * address of their base CMA region (ouch, hacky!).
> - *
> - * Return: 0 on success, or an appropriate error code otherwise
> - */
> -static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
> - int offset, int avail)
> +static struct rproc_vdev *
> +rproc_rvdev_add_device(struct rproc *rproc, struct rproc_vdev_data *rvdev_data)
> {
> - struct fw_rsc_vdev *rsc = ptr;
> - struct device *dev = &rproc->dev;
> struct rproc_vdev *rvdev;
> - int i, ret;
> + struct fw_rsc_vdev *rsc = rvdev_data->rsc;
> char name[16];
> -
> - /* make sure resource isn't truncated */
> - if (struct_size(rsc, vring, rsc->num_of_vrings) + rsc->config_len >
> - avail) {
> - dev_err(dev, "vdev rsc is truncated\n");
> - return -EINVAL;
> - }
> -
> - /* make sure reserved bytes are zeroes */
> - if (rsc->reserved[0] || rsc->reserved[1]) {
> - dev_err(dev, "vdev rsc has non zero reserved bytes\n");
> - return -EINVAL;
> - }
> -
> - dev_dbg(dev, "vdev rsc: id %d, dfeatures 0x%x, cfg len %d, %d vrings\n",
> - rsc->id, rsc->dfeatures, rsc->config_len, rsc->num_of_vrings);
> -
> - /* we currently support only two vrings per rvdev */
> - if (rsc->num_of_vrings > ARRAY_SIZE(rvdev->vring)) {
> - dev_err(dev, "too many vrings: %d\n", rsc->num_of_vrings);
> - return -EINVAL;
> - }
> + int i, ret;
>
> rvdev = kzalloc(sizeof(*rvdev), GFP_KERNEL);
> if (!rvdev)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> kref_init(&rvdev->refcount);
>
> - rvdev->id = rsc->id;
> + rvdev->id = rvdev_data->id;
> rvdev->rproc = rproc;
> - rvdev->index = rproc->nb_vdev++;
> + rvdev->index = rvdev_data->index;
>
> /* Initialise vdev subdevice */
> snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> @@ -563,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
> ret = device_register(&rvdev->dev);
> if (ret) {
> put_device(&rvdev->dev);
> - return ret;
> + return ERR_PTR(ret);
> }
>
> ret = copy_dma_range_map(&rvdev->dev, rproc->dev.parent);
> @@ -576,7 +532,7 @@ static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
> ret = dma_coerce_mask_and_coherent(&rvdev->dev,
> dma_get_mask(rproc->dev.parent));
> if (ret) {
> - dev_warn(dev,
> + dev_warn(&rvdev->dev,
> "Failed to set DMA mask %llx. Trying to continue... (%pe)\n",
> dma_get_mask(rproc->dev.parent), ERR_PTR(ret));
> }
> @@ -589,7 +545,7 @@ static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
> }
>
> /* remember the resource offset*/
> - rvdev->rsc_offset = offset;
> + rvdev->rsc_offset = rvdev_data->rsc_offset;
>
> /* allocate the vring resources */
> for (i = 0; i < rsc->num_of_vrings; i++) {
> @@ -605,21 +561,20 @@ static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
>
> rproc_add_subdev(rproc, &rvdev->subdev);
>
> - return 0;
> + return rvdev;
>
> unwind_vring_allocations:
> for (i--; i >= 0; i--)
> rproc_free_vring(&rvdev->vring[i]);
> free_rvdev:
> device_unregister(&rvdev->dev);
> - return ret;
> + return ERR_PTR(ret);
> }
>
> -void rproc_vdev_release(struct kref *ref)
> +static void rproc_rvdev_remove_device(struct rproc_vdev *rvdev)
> {
> - struct rproc_vdev *rvdev = container_of(ref, struct rproc_vdev, refcount);
> - struct rproc_vring *rvring;
> struct rproc *rproc = rvdev->rproc;
> + struct rproc_vring *rvring;
> int id;
>
> for (id = 0; id < ARRAY_SIZE(rvdev->vring); id++) {
> @@ -632,6 +587,83 @@ void rproc_vdev_release(struct kref *ref)
> device_unregister(&rvdev->dev);
> }
>
> +/**
> + * rproc_handle_vdev() - handle a vdev fw resource
> + * @rproc: the remote processor
> + * @ptr: the vring resource descriptor
> + * @offset: offset of the resource entry
> + * @avail: size of available data (for sanity checking the image)
> + *
> + * This resource entry requests the host to statically register a virtio
> + * device (vdev), and setup everything needed to support it. It contains
> + * everything needed to make it possible: the virtio device id, virtio
> + * device features, vrings information, virtio config space, etc...
> + *
> + * Before registering the vdev, the vrings are allocated from non-cacheable
> + * physically contiguous memory. Currently we only support two vrings per
> + * remote processor (temporary limitation). We might also want to consider
> + * doing the vring allocation only later when ->find_vqs() is invoked, and
> + * then release them upon ->del_vqs().
> + *
> + * Note: @da is currently not really handled correctly: we dynamically
> + * allocate it using the DMA API, ignoring requested hard coded addresses,
> + * and we don't take care of any required IOMMU programming. This is all
> + * going to be taken care of when the generic iommu-based DMA API will be
> + * merged. Meanwhile, statically-addressed iommu-based firmware images should
> + * use RSC_DEVMEM resource entries to map their required @da to the physical
> + * address of their base CMA region (ouch, hacky!).
> + *
> + * Return: 0 on success, or an appropriate error code otherwise
> + */
> +static int rproc_handle_vdev(struct rproc *rproc, void *ptr,
> + int offset, int avail)
> +{
> + struct fw_rsc_vdev *rsc = ptr;
> + struct device *dev = &rproc->dev;
> + struct rproc_vdev *rvdev;
> + struct rproc_vdev_data rvdev_data;
> +
> + /* make sure resource isn't truncated */
> + if (struct_size(rsc, vring, rsc->num_of_vrings) + rsc->config_len >
> + avail) {
> + dev_err(dev, "vdev rsc is truncated\n");
> + return -EINVAL;
> + }
> +
> + /* make sure reserved bytes are zeroes */
> + if (rsc->reserved[0] || rsc->reserved[1]) {
> + dev_err(dev, "vdev rsc has non zero reserved bytes\n");
> + return -EINVAL;
> + }
> +
> + dev_dbg(dev, "vdev rsc: id %d, dfeatures 0x%x, cfg len %d, %d vrings\n",
> + rsc->id, rsc->dfeatures, rsc->config_len, rsc->num_of_vrings);
> +
> + /* we currently support only two vrings per rvdev */
> + if (rsc->num_of_vrings > ARRAY_SIZE(rvdev->vring)) {
> + dev_err(dev, "too many vrings: %d\n", rsc->num_of_vrings);
> + return -EINVAL;
> + }
> +
> + rvdev_data.id = rsc->id;
> + rvdev_data.index = rproc->nb_vdev++;
> + rvdev_data.rsc_offset = offset;
> + rvdev_data.rsc = rsc;
> +
> + rvdev = rproc_rvdev_add_device(rproc, &rvdev_data);
> + if (IS_ERR(rvdev))
> + return PTR_ERR(rvdev);
> +
> + return 0;
> +}
> +
> +void rproc_vdev_release(struct kref *ref)
> +{
> + struct rproc_vdev *rvdev = container_of(ref, struct rproc_vdev, refcount);
> +
> + rproc_rvdev_remove_device(rvdev);
> +}
> +
> /**
> * rproc_handle_trace() - handle a shared trace buffer resource
> * @rproc: the remote processor
> --
> 2.25.1
>
next prev parent reply other threads:[~2022-03-04 18:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 16:24 [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc VirtIO device Arnaud Pouliquen
2022-01-26 16:24 ` [RFC PATCH v3 1/4] remoteproc: core: Introduce virtio device add/remove functions Arnaud Pouliquen
2022-03-04 18:29 ` Mathieu Poirier [this message]
2022-01-26 16:24 ` [RFC PATCH v3 2/4] remoteproc: core: Introduce rproc_register_rvdev function Arnaud Pouliquen
2022-03-04 18:39 ` Mathieu Poirier
2022-01-26 16:24 ` [RFC PATCH v3 3/4] remoteproc: Move rproc_vdev management to remoteproc_virtio.c Arnaud Pouliquen
2022-03-04 18:45 ` Mathieu Poirier
2022-01-26 16:24 ` [RFC PATCH v3 4/4] remoteproc: virtio: Create platform device for the remoteproc_virtio Arnaud Pouliquen
2022-03-04 18:53 ` Mathieu Poirier
2022-03-07 8:44 ` Arnaud POULIQUEN
2022-02-15 8:34 ` [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc VirtIO device Peng Fan
2022-02-15 11:11 ` Arnaud POULIQUEN
2022-02-22 13:07 ` Peng Fan
2022-02-28 18:58 ` 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=20220304182944.GA1660165@p14s \
--to=mathieu.poirier@linaro.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=bjorn.andersson@linaro.org \
--cc=bruce.ashfield@xilinx.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=robh@kernel.org \
--cc=stefanos@xilinx.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.