Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
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 v5 15/16] rpmsg: char: no dynamic endpoint management for the default one
Date: Fri, 5 Mar 2021 10:39:45 -0700	[thread overview]
Message-ID: <20210305173945.GB3885132@xps15> (raw)
In-Reply-To: <d5a451e1-3dac-f665-aabd-bd72afc88b75@foss.st.com>

On Fri, Mar 05, 2021 at 12:09:37PM +0100, Arnaud POULIQUEN wrote:
> 
> 
> On 3/4/21 7:40 PM, Mathieu Poirier wrote:
> > There has to be a capital letter at the start of the title:
> > 
> > rpmsg: char: No dynamic endpoint management for the default one
> > 
> > Please fix for all the patches.
> 
> Ok, I will update the subjects with capital letter in my next revision.
> 
> Just for my information, is it a new rule? kernel documentation [1] gives a
> canonical subject and an example without capital letter.

I don't think it is a rule but in the past few years the trend has been to
use a capital letter.  I was convinced the documentation had a capital letter
but you have proven that it doesn't so you can ignore this part if you wish.

> 
> [1]
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format
> 
> > 
> > On Fri, Feb 19, 2021 at 12:15:00PM +0100, Arnaud Pouliquen wrote:
> >> Do not dynamically manage the default endpoint. The ept address must
> >> not change.
> >> This update is needed to manage the RPMSG_CREATE_DEV_IOCTL. In this
> >> case a default endpoint is used and it's address must not change or
> >> been reused by another service.
> > 
> > The above is very difficult to understand.  I am not sure about introducing
> > RPMSG_CREATE_DEV_IOCTL in this patchset.  More on that in an upcoming comment.
> 
> The purpose of this revision was mainly to provide a view of what we could do to
> provide a more generic control interface.
> 
> To simplify the review I can remove the RPMSG_CREATE_DEV_IOCTL management and
> send it as a next step, in a separate patchset.

Yes, it would make this patchset quite simple.

> 
> > 
> >>
> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >> ---
> >>  drivers/rpmsg/rpmsg_char.c | 28 +++++++++++++++++++++-------
> >>  1 file changed, 21 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> >> index c98b0e69679b..8d3f9d6c20ad 100644
> >> --- a/drivers/rpmsg/rpmsg_char.c
> >> +++ b/drivers/rpmsg/rpmsg_char.c
> >> @@ -114,14 +114,23 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
> >>  	struct rpmsg_endpoint *ept;
> >>  	struct rpmsg_device *rpdev = eptdev->rpdev;
> >>  	struct device *dev = &eptdev->dev;
> >> +	u32 addr = eptdev->chinfo.src;
> >>  
> >>  	get_device(dev);
> >>  
> >> -	ept = rpmsg_create_ept(rpdev, rpmsg_ept_cb, eptdev, eptdev->chinfo);
> >> -	if (!ept) {
> >> -		dev_err(dev, "failed to open %s\n", eptdev->chinfo.name);
> >> -		put_device(dev);
> >> -		return -EINVAL;
> >> +	/*
> >> +	 * The RPMsg device can has been created by a ns announcement. In this
> >> +	 * case a default endpoint has been created. Reuse it to avoid to manage
> >> +	 * a new address on each open close.
> >> +	 */
> > 
> > Here too it is very difficult to understand because the comment
> > doesn't not describe what the code does.  The code creates an enpoint if it
> > has not been created, which means /dev/rpmsgX was created from the ioctl. 
> 
> Right, not enough explicit
> 
> Thanks,
> Arnaud
> 
> > 
> >> +	ept = rpdev->ept;
> >> +	if (!ept || addr != ept->addr) {
> >> +		ept = rpmsg_create_ept(rpdev, rpmsg_ept_cb, eptdev, eptdev->chinfo);
> >> +		if (!ept) {
> >> +			dev_err(dev, "failed to open %s\n", eptdev->chinfo.name);
> >> +			put_device(dev);
> >> +			return -EINVAL;
> >> +		}
> >>  	}
> >>  
> >>  	eptdev->ept = ept;
> >> @@ -133,12 +142,17 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
> >>  static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
> >>  {
> >>  	struct rpmsg_eptdev *eptdev = cdev_to_eptdev(inode->i_cdev);
> >> +	struct rpmsg_device *rpdev = eptdev->rpdev;
> >>  	struct device *dev = &eptdev->dev;
> >>  
> >> -	/* Close the endpoint, if it's not already destroyed by the parent */
> >> +	/*
> >> +	 * Close the endpoint, if it's not already destroyed by the parent and it is not the
> >> +	 * default one.
> >> +	 */
> >>  	mutex_lock(&eptdev->ept_lock);
> >>  	if (eptdev->ept) {
> >> -		rpmsg_destroy_ept(eptdev->ept);
> >> +		if (eptdev->ept != rpdev->ept)
> >> +			rpmsg_destroy_ept(eptdev->ept);
> >>  		eptdev->ept = NULL;
> >>  	}
> >>  	mutex_unlock(&eptdev->ept_lock);
> >> -- 
> >> 2.17.1
> >>

  reply	other threads:[~2021-03-05 17:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 11:14 [PATCH v5 00/16] introduce a generic IOCTL interface for RPMsg channels management Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 01/16] rpmsg: char: rename rpmsg_char_init to rpmsg_chrdev_init Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 02/16] rpmsg: move RPMSG_ADDR_ANY in user API Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 03/16] rpmsg: add short description of the IOCTL defined in UAPI Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 04/16] rpmsg: char: export eptdev create an destroy functions Arnaud Pouliquen
2021-03-02 17:57   ` Mathieu Poirier
2021-03-03 13:22     ` Arnaud POULIQUEN
2021-03-03 16:30       ` Mathieu Poirier
2021-02-19 11:14 ` [PATCH v5 05/16] rpmsg: char: dissociate the control device from the rpmsg class Arnaud Pouliquen
2021-03-02 18:01   ` Mathieu Poirier
2021-03-03 14:58     ` Arnaud POULIQUEN
2021-02-19 11:14 ` [PATCH v5 06/16] rpmsg: move the rpmsg control device from rpmsg_char to rpmsg_ctrl Arnaud Pouliquen
2021-03-02 18:35   ` Mathieu Poirier
2021-03-03 14:59     ` Arnaud POULIQUEN
2021-03-03 16:34       ` Mathieu Poirier
2021-02-19 11:14 ` [PATCH v5 07/16] rpmsg: update rpmsg_chrdev_register_device function Arnaud Pouliquen
2021-03-03 17:01   ` Mathieu Poirier
2021-02-19 11:14 ` [PATCH v5 08/16] rpmsg: glink: add sendto and trysendto ops Arnaud Pouliquen
2021-03-04 19:11   ` Mathieu Poirier
2021-03-05 10:46     ` Arnaud POULIQUEN
2021-03-05 16:55       ` Mathieu Poirier
2021-02-19 11:14 ` [PATCH v5 09/16] rpmsg: smd: " Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 10/16] rpmsg: char: use sendto to specify the message destination address Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 11/16] rpmsg: virtio: register the rpmsg_ctrl device Arnaud Pouliquen
2021-03-03 18:43   ` Mathieu Poirier
2021-03-04  9:20     ` Arnaud POULIQUEN
2021-02-19 11:14 ` [PATCH v5 12/16] rpmsg: ctrl: introduce RPMSG_CREATE_DEV_IOCTL Arnaud Pouliquen
2021-02-19 11:14 ` [PATCH v5 13/16] rpmsg: char: introduce __rpmsg_chrdev_create_eptdev function Arnaud Pouliquen
2021-03-04 18:55   ` Mathieu Poirier
2021-03-05 10:46     ` Arnaud POULIQUEN
2021-03-05 18:01       ` Mathieu Poirier
2021-03-04 19:05   ` Mathieu Poirier
2021-03-05 11:42     ` Arnaud POULIQUEN
2021-02-19 11:14 ` [PATCH v5 14/16] rpmsg: char: introduce a RPMsg driver for the RPMsg char device Arnaud Pouliquen
2021-02-19 11:15 ` [PATCH v5 15/16] rpmsg: char: no dynamic endpoint management for the default one Arnaud Pouliquen
2021-03-04 18:40   ` Mathieu Poirier
2021-03-05 11:09     ` Arnaud POULIQUEN
2021-03-05 17:39       ` Mathieu Poirier [this message]
2021-02-19 11:15 ` [PATCH v5 16/16] rpmsg: char: return an error if device already open Arnaud Pouliquen
2021-03-04 18:45   ` Mathieu Poirier
2021-03-17  9:29 ` [PATCH v5 00/16] introduce a generic IOCTL interface for RPMsg channels management 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=20210305173945.GB3885132@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=agross@kernel.org \
    --cc=arnaud.pouliquen@foss.st.com \
    --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=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