Message-ID: <3ad1b5e8-3b16-bfd2-bfd9-2d8d0ac8e8d5@foss.st.com>
Date:   Mon, 25 Jan 2021 11:52:12 +0100
From:   Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
CC:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Andy Gross <agross@...nel.org>,
        <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 04/16] rpmsg: ctrl: implement the ioctl function to
 create device

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@...s.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
>>>>

Powered by blists - more mailing lists