mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
To: Rob Herring <robh@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	Christoph Hellwig <hch@lst.de>,
	Stefano Stabellini <stefanos@xilinx.com>,
	Bruce Ashfield <bruce.ashfield@xilinx.com>
Subject: Re: [PATCH v9 4/4] remoteproc: virtio: Create platform device for the remoteproc_virtio
Date: Tue, 4 Oct 2022 18:23:39 +0200	[thread overview]
Message-ID: <97d1e574-ab68-cbd8-9300-b1a81f2dc2a9@foss.st.com> (raw)
In-Reply-To: <CAL_JsqLnm7+YQAiSeCk5Db1oNcg=rwJd4Fnve4j+-ssC-dZOHQ@mail.gmail.com>



On 10/4/22 17:43, Rob Herring wrote:
> On Tue, Oct 4, 2022 at 10:18 AM Arnaud POULIQUEN
> <arnaud.pouliquen@foss.st.com> wrote:
>>
>> Hello Rob,
>>
>> On 10/4/22 16:39, Rob Herring wrote:
>>> On Wed, Sep 21, 2022 at 03:50:44PM +0200, Arnaud Pouliquen wrote:
>>>> Define a platform driver to manage the remoteproc virtio device as
>>>> a platform devices.
>>>>
>>>> The platform device allows to pass rproc_vdev_data platform data to
>>>> specify properties that are stored in the rproc_vdev structure.
>>>>
>>>> Such approach will allow to preserve legacy remoteproc virtio device
>>>> creation but also to probe the device using device tree mechanism.
>>>>
>>>> remoteproc_virtio.c update:
>>>>   - Add rproc_virtio_driver platform driver. The probe ops replaces
>>>>     the rproc_rvdev_add_device function.
>>>>   - All reference to the rvdev->dev has been updated to rvdev-pdev->dev.
>>>>   - rproc_rvdev_release is removed as associated to the rvdev device.
>>>>   - The use of rvdev->kref counter is replaced by get/put_device on the
>>>>     remoteproc virtio platform device.
>>>>   - The vdev device no longer increments rproc device counter.
>>>>     increment/decrement is done in rproc_virtio_probe/rproc_virtio_remove
>>>>     function in charge of the vrings allocation/free.
>>>>
>>>> remoteproc_core.c update:
>>>>   Migrate from the rvdev device to the rvdev platform device.
>>>>   From this patch, when a vdev resource is found in the resource table
>>>>   the remoteproc core register a platform device.
>>>>
>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> ---
>>>>  drivers/remoteproc/remoteproc_core.c     |  12 +-
>>>>  drivers/remoteproc/remoteproc_internal.h |   2 -
>>>>  drivers/remoteproc/remoteproc_virtio.c   | 143 ++++++++++++-----------
>>>>  include/linux/remoteproc.h               |   6 +-
>>>>  4 files changed, 82 insertions(+), 81 deletions(-)
>>>
>>> [...]
>>>
>>>> +/* Platform driver */
>>>> +static const struct of_device_id rproc_virtio_match[] = {
>>>> +    { .compatible = "virtio,rproc" },
>>>
>>> This is not documented. Add a binding schema if you need DT support.
>>
>>
>> Mathieu also pointed this out to me in V8, you can see the discussion here [1]
>>
>> Here is an extract:
>> "Yes I saw the warning, but for this first series it is not possible to declare
>> the associated "rproc-virtio" device in device tree.
>> So at this step it seems not make senses to create the devicetree bindings file.
>> More than that I don't know how I could justify the properties in bindings if
>> there is not driver code associated.
>>
>> So i would be in favor of not adding the bindings in this series but to define
>> bindings in the first patch of my "step 2" series; as done on my github:
>> https://github.com/arnopo/linux/commit/9616d89a4f478cf78865a244efcde108d900f69f
>> "
> 
> Okay, since I only just started checking this (in a more reliable way
> than checkpatch does).
> 
> But why do you need the DT match entry if it is not usable yet? You
> could just add that in later when the binding is defined. Review of
> the binding could say that 'virtio,rproc' should be something else and
> you'd have to change it.

Probably because I am too formatted to add a compatible when I create a driver,
this solution yet logical did not come to my mind...

I will send a fix to suppress the compatible.

Thanks,
Arnaud

> 
> Rob

  reply	other threads:[~2022-10-04 16:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 13:50 [PATCH v9 0/4] remoteproc: restructure the remoteproc VirtIO device Arnaud Pouliquen
2022-09-21 13:50 ` [PATCH v9 1/4] remoteproc: core: Introduce rproc_rvdev_add_device function Arnaud Pouliquen
2022-09-21 13:50 ` [PATCH v9 2/4] remoteproc: core: Introduce rproc_add_rvdev function Arnaud Pouliquen
2022-09-21 13:50 ` [PATCH v9 3/4] remoteproc: Move rproc_vdev management to remoteproc_virtio.c Arnaud Pouliquen
2022-09-21 13:50 ` [PATCH v9 4/4] remoteproc: virtio: Create platform device for the remoteproc_virtio Arnaud Pouliquen
2022-10-04 14:39   ` Rob Herring
2022-10-04 15:18     ` Arnaud POULIQUEN
2022-10-04 15:43       ` Rob Herring
2022-10-04 16:23         ` Arnaud POULIQUEN [this message]
2022-09-21 17:17 ` [PATCH v9 0/4] remoteproc: restructure the remoteproc VirtIO device 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=97d1e574-ab68-cbd8-9300-b1a81f2dc2a9@foss.st.com \
    --to=arnaud.pouliquen@foss.st.com \
    --cc=andersson@kernel.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=mathieu.poirier@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®