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@xxxxxxxxxxx>
>>>> ---
>>>> 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
>>>>
