From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Ohad Ben-Cohen <ohad@wizery.com>, Andy Gross <agross@kernel.org>,
<linux-remoteproc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH v2 04/16] rpmsg: ctrl: implement the ioctl function to create device
Date: Mon, 25 Jan 2021 11:52:12 +0100 [thread overview]
Message-ID: <3ad1b5e8-3b16-bfd2-bfd9-2d8d0ac8e8d5@foss.st.com> (raw)
In-Reply-To: <20210122205934.GA866146@xps15>
Hi Mathieu,
On 1/22/21 9:59 PM, Mathieu Poirier wrote:
> On Fri, Jan 22, 2021 at 02:05:27PM +0100, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 1/22/21 12:52 AM, Mathieu Poirier wrote:
>>> On Tue, Dec 22, 2020 at 11:57:14AM +0100, Arnaud Pouliquen wrote:
>>>> Implement the ioctl function that parses the list of
>>>> rpmsg drivers registered to create an associated device.
>>>> To be ISO user API, in a first step, the driver_override
>>>> is only allowed for the RPMsg raw service, supported by the
>>>> rpmsg_char driver.
>>>>
>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> ---
>>>> drivers/rpmsg/rpmsg_ctrl.c | 43 ++++++++++++++++++++++++++++++++++++--
>>>> 1 file changed, 41 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/rpmsg/rpmsg_ctrl.c b/drivers/rpmsg/rpmsg_ctrl.c
>>>> index 065e2e304019..8381b5b2b794 100644
>>>> --- a/drivers/rpmsg/rpmsg_ctrl.c
>>>> +++ b/drivers/rpmsg/rpmsg_ctrl.c
>>>> @@ -56,12 +56,51 @@ static int rpmsg_ctrl_dev_open(struct inode *inode, struct file *filp)
>>>> return 0;
>>>> }
>>>>
>>>> +static const char *rpmsg_ctrl_get_drv_name(u32 service)
>>>> +{
>>>> + struct rpmsg_ctl_info *drv_info;
>>>> +
>>>> + list_for_each_entry(drv_info, &rpmsg_drv_list, node) {
>>>> + if (drv_info->ctrl->service == service)
>>>> + return drv_info->ctrl->drv_name;
>>>> + }
>>>> +
>>>
>>> I'm unsure about the above... To me this looks like what the .match() function
>>> of a bus would do. And when I read Bjorn's comment he brought up the
>>> auxiliary_bus. I don't know about the auxiliary_bus but it is worth looking
>>> into. Registering with a bus would streamline a lot of the code in this
>>> patchset.
>>
>> As answered Bjorn, we already have the RPMsg bus to manage the rpmsg devices.
>> Look like duplication from my POV, except if the IOCTL does not manage channel
>> but only endpoint.
>>
>> In my design I considered that the rpmsg_ctrl creates a channel associated to a
>> rpmsg_device such as the RPMsg ns_announcement.
>>
>> Based on this assumption, if we implement the auxiliary_bus (or other) for the
>> rpmsg_ctrl a RPMsg driver will have to manage the probe by rpmsg_bus and by the
>> auxillary bus. The probe from the auxiliary bus would lead to the creation of an
>> RPMsg device on the rpmsg_bus, so a duplication with cross dependencies and
>> would probably make tricky the remove part.
>>
>> That said, I think the design depends on the functionality that should be
>> implemented in the rpmsg_ctrl. Here is an alternative approach based on the
>> auxiliary bus, which I'm starting to think about:
>>
>> The current approach of the rpmsg_char driver is to use the IOCTRL interface to
>> instantiate a cdev with an endpoint (the RPMsg device is associated with the
>> ioctl dev). This would correspond to the use of an auxiliary bus to manage local
>> endpoint creations.
>>
>> We could therefore consider an RPMsg name service based on an RPmsg device. This
>> RPMsg device would register a kind of "RPMsg service endpoint" driver on the
>> auxiliary rpmsg_ioctl bus.
>> The rpmsg_ctrl will be used to instantiate the endpoints for this RPMsg device.
>> on user application request the rpmsg_ctrl will call the appropriate auxiliary
>> device to create an endpoint.
>>
>> If we consider that one objective of this series is to allow application to
>> initiate the communication with the remote processor, so to be able to initiate
>> the service (ns announcement sent to the remote processor).
>> This implies that:
>> -either the RPMsg device has been probed first by a remote ns announcement or by
>> a Linux kernel driver using the "driver_override", to register an auxiliary
>> device. In this case an endpoint will be created associated to the RPMsg service
>> - or create a RPMsg device on first ioctl endpoint creation request, if it does
>> not exist (that could trig a NS announcement to remote processor).
>>
>> But I'm not sure that this approach would work with QCOM RPMsg backends...
>>
>
> I don't think there is a way forward with this set without a clear understanding
> of the Glink and SMD drivers. I have already spent a fair amount of time in the
> Glink driver and will continue on Monday with SMD.
>
>>>
>>> I'm out of time for today - I will continue tomorrow.
>>
>> It seems to me that the main point to step forward is to clarify the global
>> design and features of the rpmsg-ctrl.
>> Depending on the decision taken, this series could be trashed and rewritten from
>> a blank page...To not lost to much time on the series don't hesitate to limit
>> the review to the minimum.
>>
>
> I doubt you will ever get clear guidelines on the whole solution. I will get
> back to you once I am done with the SMD driver, which should be in the
> latter part of next week.
Thanks for your time past on this topic!
I don't expect a clear guidance but that we clarify the objective of this RPMsg
IOCTL. A first step would be sure that we are in line with the objective of the
RPMsg IOCTL.
For instance should we continue in a way to have the rpmsg_char more "rpmsg
service" generic, relying on a rpmsg_ioctl for the control part? Or should we
implement something independent (with is own API) to limit dependency with QCOM
backends constraints?
At the end, if implementing a IOCTL interface directly in the RPMsg TTY seems to
you and Bjorn simpler, I can also go on this way...
On my side I expect to find time this week to prototype a RPMSg ioctl using the
auxiliary bus to better understand involved mechanism.
Thanks,
Arnaud
>
>> Thanks,
>> Arnaud
>>
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>> + return NULL;
>>>> +}
>>>> +
>>>> static long rpmsg_ctrl_dev_ioctl(struct file *fp, unsigned int cmd,
>>>> unsigned long arg)
>>>> {
>>>> struct rpmsg_ctrl_dev *ctrldev = fp->private_data;
>>>> -
>>>> - dev_info(&ctrldev->dev, "Control not yet implemented\n");
>>>> + void __user *argp = (void __user *)arg;
>>>> + struct rpmsg_channel_info chinfo;
>>>> + struct rpmsg_endpoint_info eptinfo;
>>>> + struct rpmsg_device *newch;
>>>> +
>>>> + if (cmd != RPMSG_CREATE_EPT_IOCTL)
>>>> + return -EINVAL;
>>>> +
>>>> + if (copy_from_user(&eptinfo, argp, sizeof(eptinfo)))
>>>> + return -EFAULT;
>>>> +
>>>> + /*
>>>> + * In a frst step only the rpmsg_raw service is supported.
>>>> + * The override is foorced to RPMSG_RAW_SERVICE
>>>> + */
>>>> + chinfo.driver_override = rpmsg_ctrl_get_drv_name(RPMSG_RAW_SERVICE);
>>>> + if (!chinfo.driver_override)
>>>> + return -ENODEV;
>>>> +
>>>> + memcpy(chinfo.name, eptinfo.name, RPMSG_NAME_SIZE);
>>>> + chinfo.name[RPMSG_NAME_SIZE - 1] = '\0';
>>>> + chinfo.src = eptinfo.src;
>>>> + chinfo.dst = eptinfo.dst;
>>>> +
>>>> + newch = rpmsg_create_channel(ctrldev->rpdev, &chinfo);
>>>> + if (!newch) {
>>>> + dev_err(&ctrldev->dev, "rpmsg_create_channel failed\n");
>>>> + return -ENXIO;
>>>> + }
>>>>
>>>> return 0;
>>>> };
>>>> --
>>>> 2.17.1
>>>>
next prev parent reply other threads:[~2021-01-26 5:22 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-22 10:57 [PATCH v2 00/16] introduce generic IOCTL interface for RPMsg channels management Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 01/16] rpmsg: introduce RPMsg control driver for channel creation Arnaud Pouliquen
2020-12-22 16:45 ` Randy Dunlap
2021-01-05 0:21 ` Bjorn Andersson
2021-01-21 23:31 ` Mathieu Poirier
2020-12-22 10:57 ` [PATCH v2 02/16] rpmsg: add RPMsg control API to register service Arnaud Pouliquen
2021-01-05 0:34 ` Bjorn Andersson
2021-01-05 16:53 ` Arnaud POULIQUEN
2021-01-21 23:46 ` Mathieu Poirier
2020-12-22 10:57 ` [PATCH v2 03/16] rpmsg: add override field in channel info Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 04/16] rpmsg: ctrl: implement the ioctl function to create device Arnaud Pouliquen
2021-01-05 1:33 ` Bjorn Andersson
2021-01-05 18:07 ` Arnaud POULIQUEN
2021-01-21 23:52 ` Mathieu Poirier
2021-01-22 13:05 ` Arnaud POULIQUEN
2021-01-22 20:59 ` Mathieu Poirier
2021-01-25 10:52 ` Arnaud POULIQUEN [this message]
2021-01-29 0:13 ` Mathieu Poirier
2021-01-29 9:45 ` Arnaud POULIQUEN
2020-12-22 10:57 ` [PATCH v2 05/16] rpmsg: ns: initialize channel info override field Arnaud Pouliquen
2021-01-05 0:38 ` Bjorn Andersson
2021-01-05 17:02 ` Arnaud POULIQUEN
2020-12-22 10:57 ` [PATCH v2 06/16] rpmsg: add helper to register the rpmsg ctrl device Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 07/16] rpmsg: char: clean up rpmsg class Arnaud Pouliquen
2021-01-05 0:47 ` Bjorn Andersson
2021-01-05 0:54 ` Bjorn Andersson
2021-01-05 17:03 ` Arnaud POULIQUEN
2020-12-22 10:57 ` [PATCH v2 08/16] rpmsg: char: make char rpmsg a rpmsg device without the control part Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 09/16] rpmsg: char: register RPMsg raw service to the ioctl interface Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 10/16] rpmsg: char: allow only one endpoint per device Arnaud Pouliquen
2021-01-05 0:59 ` Bjorn Andersson
2021-01-05 17:05 ` Arnaud POULIQUEN
2020-12-22 10:57 ` [PATCH v2 11/16] rpmsg: char: check destination address is not null Arnaud Pouliquen
2021-01-05 1:03 ` Bjorn Andersson
2021-01-05 17:08 ` Arnaud POULIQUEN
2020-12-22 10:57 ` [PATCH v2 12/16] rpmsg: virtio: use the driver_override in channel creation ops Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 13/16] rpmsg: virtio: probe the rpmsg_ctl device Arnaud Pouliquen
2020-12-29 4:16 ` kernel test robot
2021-01-04 12:59 ` Dan Carpenter
2020-12-22 10:57 ` [PATCH v2 14/16] rpmsg: glink: add create and release rpmsg channel ops Arnaud Pouliquen
2021-01-05 1:08 ` Bjorn Andersson
2021-01-05 17:29 ` Arnaud POULIQUEN
2020-12-22 10:57 ` [PATCH v2 15/16] rpmsg: smd: " Arnaud Pouliquen
2020-12-22 10:57 ` [PATCH v2 16/16] rpmsg: replace rpmsg_chrdev_register_device use Arnaud Pouliquen
2021-01-05 1:10 ` Bjorn Andersson
2021-01-04 23:03 ` [PATCH v2 00/16] introduce generic IOCTL interface for RPMsg channels management Bjorn Andersson
2021-01-05 16:59 ` Arnaud POULIQUEN
2021-01-13 20:31 ` Mathieu Poirier
2021-01-14 9:05 ` Arnaud POULIQUEN
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=3ad1b5e8-3b16-bfd2-bfd9-2d8d0ac8e8d5@foss.st.com \
--to=arnaud.pouliquen@foss.st.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).