Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2829538pxb; Fri, 8 Oct 2021 16:43:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7X4LjNvCNEWi8JW5YwtBFi+5JM5gtMqXrxlK19Tm1Kc1P16bGKVVloM9vQUzkeXe8XcDl X-Received: by 2002:a17:902:f551:b0:13f:2b8:aff7 with SMTP id h17-20020a170902f55100b0013f02b8aff7mr12034113plf.89.1633736622522; Fri, 08 Oct 2021 16:43:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633736622; cv=none; d=google.com; s=arc-20160816; b=Dhh9xGfIdHrNmo779mTjKuO5bXOhDoYDVrBK5M7a1H7B1WP2RqGcxVe15HPrhd6B0F wQuDB2ZIRBKRiVUih8Y0IaJr5MNETeTkV/6r51cPZen08G5gHadgTmUOFOE50f77qe9h HuF5gzKe+EnYiU3+oTkOtYWyD5tk8JWMAHm2xluBphFKfVNffy78kr8xqw19G2YCydSt pqxIUr3M02XEL8AnDY99aTcwMgGt/GV6BepGRuCcPp5PYONhm5xkUMvpb/9vHPwZyd9g imFkRtaKSfjPqBmLWrXfMC0r+tIJKaJhJhdFDWSsQgevNEdJO2LPoee1WaFWa1fPB9kF P9jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=E2HRXF4ISVU2+cymW013Lc9bdY2GyNOKabizpiOqGQY=; b=MpiiNRUoCjlaXbaT4cEl4+OyiOSTURA92PAuSKWx5rygZFVlcpU49XSjawcPAM89QZ 5MXD8Ttl3UC8j3p4AUCNzC4jOJj1gH8RL7vNgZTDkte3b9PHhuhZCEJusLdPLPHmZNfD f6/DA7O4UYDeeYyTOFkVs6FTJvQwmOi45WjLpvboVYnPqp1f3wFkjDhSihFZK4TdVumZ M44q33rQEUV0GiSFpT5c2et6ogpOWPsFWTYxvNxWSAcX/nv6ihP2P+V073YOqum+fSqZ ZykY20UQBJGmyUehD1iL14opjQmEoKzOrV/WfzkwsDC811uzZvfZs9K8D6wfsmj8AFN4 Iw9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nZGBkZgq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si836668pgi.568.2021.10.08.16.43.30; Fri, 08 Oct 2021 16:43:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nZGBkZgq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243984AbhJHXnT (ORCPT + 99 others); Fri, 8 Oct 2021 19:43:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244016AbhJHXnN (ORCPT ); Fri, 8 Oct 2021 19:43:13 -0400 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E70E0C061764 for ; Fri, 8 Oct 2021 16:41:17 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id 5-20020a9d0685000000b0054706d7b8e5so13534706otx.3 for ; Fri, 08 Oct 2021 16:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=E2HRXF4ISVU2+cymW013Lc9bdY2GyNOKabizpiOqGQY=; b=nZGBkZgqbaOZWKC81X/38uDT/zKLALPhkwxZIS/ruJkI+DpGMOkOJYJbU4QEJue47Q WKXE+3iF+oyuMn7De5rw+x4XGSjsIV4eEm5WDXTd+lwnUCyyNKHD77lhBjxDHcEgfA70 s/GEj7NCSJw/bcZPaVcqjfgeaM07NOIGUUdbsQ1eSB+OGwgqX031BwWFdX7AYovBfhUf VxohewkMyZjaVQ0NZf8QIQjTESt8c2SeeUfcRp/Q1yxxqMHzSY6YbLC53b7rZRc05Onb FMiYxCKyC7PLT8onmNnClHi6MUnamkUNAfETl4rqFJLPhAaCGonmSVh4wVdygxtM3GH9 zBEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=E2HRXF4ISVU2+cymW013Lc9bdY2GyNOKabizpiOqGQY=; b=kQ7Z5qKXybZ1HqeVmDhM9d9GtLqqs20iSwsI4IyhG4Er3hH8rM6ECxRMIoJ4Qelf1E MDrr+X6KGq75St53MS8SQ1JMpdYG8O6HBqF6dlqE/gk6tYrf6EBRFGA5lcsC5ilML0uP aRSKTTTZWfe1hSJaYT18lkWuGiV8kfFNdyfFylyXWIQEozIFMYkHG9E5UE5tuE+CodMD lN7/zBYqb37IklmhqPYYcFbYj6N0fHpSMQs7IYTszFGZNl3TaCWOP7m1LIoa2aoLiKmL L2KQ7aIasCwihvf7KAEI3a064bjt0yFSzJ+L4eMeQKyQQG5fcu8t4T1b1BaEnlHOTESV 2Okw== X-Gm-Message-State: AOAM532083Yv6IRzweYqqYkgSb3c1C2GjIXPdffze+QOEGYxnpdVJBwu jWbyOaeE0DX4cUM02G1obYs9zA== X-Received: by 2002:a9d:64c:: with SMTP id 70mr10690738otn.59.1633736475832; Fri, 08 Oct 2021 16:41:15 -0700 (PDT) Received: from ripper ([2600:1700:a0:3dc8:205:1bff:fec0:b9b3]) by smtp.gmail.com with ESMTPSA id l25sm145046oot.36.2021.10.08.16.41.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 16:41:15 -0700 (PDT) Date: Fri, 8 Oct 2021 16:42:53 -0700 From: Bjorn Andersson To: Arnaud Pouliquen Cc: Ohad Ben-Cohen , Mathieu Poirier , linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, julien.massot@iot.bzh Subject: Re: [PATCH v4 3/4] rpmsg: char: Add possibility to use default endpoint of the rpmsg device. Message-ID: References: <20210712131900.24752-1-arnaud.pouliquen@foss.st.com> <20210712131900.24752-4-arnaud.pouliquen@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210712131900.24752-4-arnaud.pouliquen@foss.st.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 12 Jul 06:18 PDT 2021, Arnaud Pouliquen wrote: > Current implementation create/destroy a new endpoint on each > rpmsg_eptdev_open/rpmsg_eptdev_release calls. > > For a rpmsg device created by the NS announcement mechanism we need to > use a unique static endpoint that is the default rpmsg device endpoint > associated to the channel. > Why do you need this endpoint associated with the channel? Afaict the read/write operations still operate on eptdev->ept, so who does use the default endpoint for the device? > This patch prepares the introduction of a rpmsg channel device for the > char device. The rpmsg channel device will require a default endpoint to > communicate to the remote processor. > > Add the static_ept field in rpmsg_eptdev structure. This boolean > determines the behavior on rpmsg_eptdev_open and rpmsg_eptdev_release call. > > - If static_ept == false: > Use the legacy behavior by creating a new endpoint each time > rpmsg_eptdev_open is called and release it when rpmsg_eptdev_release > is called on /dev/rpmsgX device open/close. > > - If static_ept == true: > use the rpmsg device default endpoint for the communication. > - Address the update of _rpmsg_chrdev_eptdev_create in e separate patch for readability. > > Add protection in rpmsg_eptdev_ioctl to prevent to destroy a default endpoint. > > Signed-off-by: Arnaud Pouliquen > Reviewed-by: Mathieu Poirier > Tested-by: Julien Massot > --- > drivers/rpmsg/rpmsg_char.c | 21 +++++++++++++++++++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c > index 50b7d4b00175..bd728d90ba4c 100644 > --- a/drivers/rpmsg/rpmsg_char.c > +++ b/drivers/rpmsg/rpmsg_char.c > @@ -45,6 +45,8 @@ static DEFINE_IDA(rpmsg_minor_ida); > * @queue_lock: synchronization of @queue operations > * @queue: incoming message queue > * @readq: wait object for incoming queue > + * @static_ept: specify if the endpoint has to be created at each device opening or > + * if the default endpoint should be used. > */ > struct rpmsg_eptdev { > struct device dev; > @@ -59,6 +61,8 @@ struct rpmsg_eptdev { > spinlock_t queue_lock; > struct sk_buff_head queue; > wait_queue_head_t readq; > + > + bool static_ept; I think you can skip rpmsg_create_default_ept() if you just make this struct rpmsg_endpoint *. > }; > > int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data) > @@ -116,7 +120,15 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp) > > get_device(dev); > > - ept = rpmsg_create_ept(rpdev, rpmsg_ept_cb, eptdev, eptdev->chinfo); > + /* > + * If the static_ept is set to true, the rpmsg device default endpoint is used. > + * Else a new endpoint is created on open that will be destroyed on release. > + */ > + if (eptdev->static_ept) > + ept = rpdev->ept; This would be: if (eptdev->static_ept) ept = eptdev->static_ept; > + else > + 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); > @@ -137,7 +149,8 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp) > /* Close the endpoint, if it's not already destroyed by the parent */ > mutex_lock(&eptdev->ept_lock); > if (eptdev->ept) { > - rpmsg_destroy_ept(eptdev->ept); > + if (!eptdev->static_ept) > + rpmsg_destroy_ept(eptdev->ept); > eptdev->ept = NULL; > } > mutex_unlock(&eptdev->ept_lock); > @@ -264,6 +277,10 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd, > if (cmd != RPMSG_DESTROY_EPT_IOCTL) > return -EINVAL; > > + /* Don't allow to destroy a default endpoint. */ > + if (eptdev->ept == eptdev->rpdev->ept) And this would be if: if (eptdev->static_ept) return -EPERM; Wouldn't -EINVAL or something be better than -EPERM when you try to destroy one of these endpoints? It's not that we don't have permission, it's that it's not a valid operation on this object. Regards, Bjorn > + return -EPERM; > + > return rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL); > } > > -- > 2.17.1 >