All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: <linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<arnaud.pouliquen@foss.st.com>
Subject: [PATCH 0/4] rpmsg: ctrl: Add ability to instantiate rpmsg device locally
Date: Fri, 4 Jun 2021 11:14:02 +0200	[thread overview]
Message-ID: <20210604091406.15901-1-arnaud.pouliquen@foss.st.com> (raw)

Purpose:
  Allow the user space application to create and release an rpmsg device by adding
  rpmsg ioctrl to the /dev/rpmsg_ctrl interface
    
Aim:
  The current implementation is based on the enumeration of services by the 
  remote processor to create a new channel and instantiate associated rpmsg device.
  There is no solution to create a rpmsg channel on user application request.
  If the rpmsg char driver allows adding a new endpoint over an existing channel, it
  does not offer the ability to create a new one.
  Adding the IOCTRL to instantiate rpmsg channels from the user application will allow
  to dynamically create and destroy rpmsg devices. Some examples of use are:
  - activate the service at the initiative of the application,
  - remove the communication on a specific channel before entering the suspend mode,
  - creating a temporary channel for debugging purposes.

Concerns:
  This implementation is very simple but allows the user application to create rpmsg devices
  without any limitations.
  - A device can be created even if there is no match with the driver (and it is difficult to
    check a match with module drivers).
  - It is not really possible to add a counter to limit the number of devices, because a device
    can be released by the remote side.
  
  The question is: should we add protection? Notice that there is no protection for RPMSG_CREATE_EPT_IOCTL.

  If this is not considered safe, another approach could be to create an rpmsg_ctrl API to add controls.
  This API would be used by a rpmsg driver to add is own user controls, such as creating/deleting devices.

How to test it:
  - This series can be applied on git/andersson/remoteproc.git for-next branch (dc0e14fa833b)
    + the "Restructure the rpmsg char to decorrelate the control part" series[1]
  - to test the ioctrl, a rpmsgexportdev tool is available here: https://github.com/arnopo/rpmsgexport

[1]https://patchwork.kernel.org/project/linux-remoteproc/list/?series=483793

Arnaud Pouliquen (4):
  rpmsg: ctrl: Introduce RPMSG_CREATE_DEV_IOCTL
  rpmsg: ctrl: Introduce RPMSG_RELEASE_DEV_IOCTL
  rpmsg: ctrl: Add check on rpmsg device removability from user space
  rpmsg: Add a removable attribute to the rpmsg device

 drivers/rpmsg/rpmsg_core.c |  2 ++
 drivers/rpmsg/rpmsg_ctrl.c | 52 +++++++++++++++++++++++++++++++++++---
 include/linux/rpmsg.h      |  2 ++
 include/uapi/linux/rpmsg.h | 10 ++++++++
 4 files changed, 62 insertions(+), 4 deletions(-)

-- 
2.17.1


             reply	other threads:[~2021-06-04  9:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04  9:14 Arnaud Pouliquen [this message]
2021-06-04  9:14 ` [PATCH 1/4] rpmsg: ctrl: Introduce RPMSG_CREATE_DEV_IOCTL Arnaud Pouliquen
2021-06-15 17:53   ` Mathieu Poirier
2021-06-16  8:12     ` Arnaud POULIQUEN
2021-06-21  9:35       ` Arnaud POULIQUEN
2021-06-04  9:14 ` [PATCH 2/4] rpmsg: ctrl: Introduce RPMSG_RELEASE_DEV_IOCTL Arnaud Pouliquen
2021-06-15 17:38   ` Mathieu Poirier
2021-06-16  8:13     ` Arnaud POULIQUEN
2021-06-04  9:14 ` [PATCH 3/4] rpmsg: ctrl: Add check on rpmsg device removability from user space Arnaud Pouliquen
2021-06-15 17:46   ` Mathieu Poirier
2021-06-16  9:30     ` Arnaud POULIQUEN
2021-06-16 17:15       ` Mathieu Poirier
2021-06-17  8:02         ` Arnaud POULIQUEN
2021-06-17 16:55           ` Arnaud POULIQUEN
2021-06-17 16:56           ` Mathieu Poirier
2021-06-04  9:14 ` [PATCH 4/4] rpmsg: Add a removable attribute to the rpmsg device Arnaud Pouliquen
2021-06-15 17:48   ` 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=20210604091406.15901-1-arnaud.pouliquen@foss.st.com \
    --to=arnaud.pouliquen@foss.st.com \
    --cc=bjorn.andersson@linaro.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 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.