Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp508754pxk; Thu, 1 Oct 2020 07:48:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbUF7SrBX0BTr7oGtM16nOokTZpFkkCdPTbET/+1s96idmbHeoCNbY04L2FDhkFC7deW25 X-Received: by 2002:aa7:db02:: with SMTP id t2mr8388069eds.95.1601563700052; Thu, 01 Oct 2020 07:48:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601563700; cv=none; d=google.com; s=arc-20160816; b=Olc06OuHYdXMmktlRjjuo7beC4dhpGD6lqR02td/CAlWKP9tXaiNjJaIafKhlgUIgu vTx8c0a4uW3Q2MLHHIdD0eLZqg4lkiC2Uw8RfxfNTMNz0yoSfXhojPLz0OdsznCr48nf 6oW4FK/Rfdmms8gTXnrtCksM2maEdWUX205CgUdfCUAwUaSR8DSLT4Z6gYh2en1F2/Ip ogDHs+b7Q8zS5AITj9+q30V/lmLJLm10NvaP1y2oaS17Ntc0rLOO/gE7xz3j6a2mMIWF /lfH0xqzRb5WdJujABeicbwwJbg51htMH9LW1bUAQAipp0MoVxId1kufXMMSUPN++B79 aIlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=MfBPhNoT6FPttKa4wn46gmWhQf3voOCyoRh7mAmqjtQ=; b=fVUx10MPpzKxxXW45wGUFVjJjKClioVxCn377mF9/hZ4VotXPDeeUQhCVgmhqCdfDl /6KEbbNSSO9jxt0cKzuqovWQnqR1MaBg/MZWHUzX5zVoVBfM6YpC0gIQrRIdkLakUGRs hJsaPbfA6xe9v8KqYxWIG8QVvGlNHV5cDp6eAoWnYoq78CfqWoGQom+xG9XOqyUtLEi9 Ga4MLxzgv1SUc1UFCUsMeb5HgUPwgTLcrrLa+XEZNKyZB3ogzG+Qo+yNcVcsaj5LDOlg tgNkLDUZ3RPdLIMzj7UZiZJXHU1dxH3YF+kC7VGTjguHKvR/bf0n6+EPp6J0NtivycEh HXhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=lmaJnxIv; 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=st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x7si3680376eje.505.2020.10.01.07.47.55; Thu, 01 Oct 2020 07:48:20 -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=@st.com header.s=STMicroelectronics header.b=lmaJnxIv; 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=st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732410AbgJAOrD (ORCPT + 99 others); Thu, 1 Oct 2020 10:47:03 -0400 Received: from mx07-00178001.pphosted.com ([185.132.182.106]:17860 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732020AbgJAOrC (ORCPT ); Thu, 1 Oct 2020 10:47:02 -0400 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 091EfdNK008888; Thu, 1 Oct 2020 16:46:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=STMicroelectronics; bh=MfBPhNoT6FPttKa4wn46gmWhQf3voOCyoRh7mAmqjtQ=; b=lmaJnxIvuhVdBBphI1l6uSPcpDE5J76TxZx5DxECVq/BICBYIkO6ryeTcOZR2bwfhGd+ xcDTJIB82nD85CgadXA65Hjh+zb5+JMYXdiBL6ljuO/sFTRdhQbZamLnVA5kqJKIz/E5 ltdVAb/405w6k1o8pQyg4LALZAfxzuIAXcTZKWFdmviyomyfzIIA6HhNWBmfXz/oGmEG vAHrkBC9tIX3iIWjRBQ4cRv3BAQ9Q8x8wQCJTzkcxOJ1qIos9XeOV9Awj02Cwx7che9m nwydvMdLV/1wqvWdNlgmRv5K0uMTGquAMhFVoljoebH9+3bEjTAJdkYbJAIsi1YjFZ0f dA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 33su4054tg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Oct 2020 16:46:57 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8251F10002A; Thu, 1 Oct 2020 16:46:56 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag3node1.st.com [10.75.127.7]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 6EF2F2B2057; Thu, 1 Oct 2020 16:46:56 +0200 (CEST) Received: from lmecxl0889.tpe.st.com (10.75.127.51) by SFHDAG3NODE1.st.com (10.75.127.7) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Oct 2020 16:46:55 +0200 Subject: Re: [PATCH 02/10] rpmsg: core: Add channel creation internal API To: Guennadi Liakhovetski , Mathieu Poirier CC: "ohad@wizery.com" , "bjorn.andersson@linaro.org" , Loic PALLARDY , "linux-remoteproc@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20200922001000.899956-1-mathieu.poirier@linaro.org> <20200922001000.899956-3-mathieu.poirier@linaro.org> <20200930063553.GB20683@ubuntu> From: Arnaud POULIQUEN Message-ID: Date: Thu, 1 Oct 2020 16:46:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200930063553.GB20683@ubuntu> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.51] X-ClientProxiedBy: SFHDAG4NODE3.st.com (10.75.127.12) To SFHDAG3NODE1.st.com (10.75.127.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-01_04:2020-10-01,2020-10-01 signatures=0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/30/20 8:35 AM, Guennadi Liakhovetski wrote: > On Mon, Sep 21, 2020 at 06:09:52PM -0600, Mathieu Poirier wrote: >> From: Arnaud Pouliquen >> >> Add the channel creation API as a first step to be able to define the >> name service announcement as a rpmsg driver independent from the RPMsg >> virtio bus. >> >> Signed-off-by: Arnaud Pouliquen >> --- >> drivers/rpmsg/rpmsg_core.c | 45 ++++++++++++++++++++++++++++++++++ >> drivers/rpmsg/rpmsg_internal.h | 12 +++++++++ >> 2 files changed, 57 insertions(+) >> >> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c >> index 91de940896e3..50a835eaf1ba 100644 >> --- a/drivers/rpmsg/rpmsg_core.c >> +++ b/drivers/rpmsg/rpmsg_core.c >> @@ -20,6 +20,51 @@ >> >> #include "rpmsg_internal.h" >> >> +/** >> + * rpmsg_create_channel() - create a new rpmsg channel >> + * using its name and address info. >> + * @rpdev: rpmsg driver > > device > >> + * @chinfo: channel_info to bind >> + * >> + * Returns a pointer to the new rpmsg device on success, or NULL on error. >> + */ >> +struct rpmsg_device * >> + rpmsg_create_channel(struct rpmsg_device *rpdev, > > You might call this nitpicking, but we already have two indentation styles for > functions: > > return_type function(type1 arg1, > ...) > > (my personal preference, it also has sub-variants - depending on the aligning > of the second line and any following lines, and one more moving "type1 arg1" > to the second line) > > return_type > function(... > > and now you're also introducing the third style - with "function" indented... > Maybe we don't need more of those, particularly since now with 100 chars per > line in most cases the very first style can be used. Right, bad coding style. > >> + struct rpmsg_channel_info *chinfo) >> +{ >> + if (WARN_ON(!rpdev)) >> + return NULL; >> + if (!rpdev->ops || !rpdev->ops->create_channel) { >> + dev_err(&rpdev->dev, "no create_channel ops found\n"); >> + return NULL; >> + } >> + >> + return rpdev->ops->create_channel(rpdev, chinfo); >> +} >> +EXPORT_SYMBOL(rpmsg_create_channel); >> + >> +/** >> + * rpmsg_release_channel() - release a rpmsg channel >> + * using its name and address info. >> + * @rpdev: rpmsg driver > > device > >> + * @chinfo: channel_info to bind >> + * >> + * Returns 0 on success or an appropriate error value. >> + */ >> +int rpmsg_release_channel(struct rpmsg_device *rpdev, >> + struct rpmsg_channel_info *chinfo) >> +{ >> + if (WARN_ON(!rpdev)) >> + return -EINVAL; >> + if (!rpdev->ops || !rpdev->ops->release_channel) { >> + dev_err(&rpdev->dev, "no release_channel ops found\n"); >> + return -EPERM; > > ENOSYS or EOPNOTSUPP? I'm never sure which one is appropriate for > this kind of errors. For coherency with the other RPMsg API functions, could be ENXIO... > >> + } >> + >> + return rpdev->ops->release_channel(rpdev, chinfo); >> +} >> +EXPORT_SYMBOL(rpmsg_release_channel); >> + >> /** >> * rpmsg_create_ept() - create a new rpmsg_endpoint >> * @rpdev: rpmsg channel device >> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h >> index 3fc83cd50e98..587f723757d4 100644 >> --- a/drivers/rpmsg/rpmsg_internal.h >> +++ b/drivers/rpmsg/rpmsg_internal.h >> @@ -20,6 +20,8 @@ >> >> /** >> * struct rpmsg_device_ops - indirection table for the rpmsg_device operations >> + * @create_channel: create backend-specific channel, optional >> + * @release_channel: release backend-specific channel, optional > > Are they really optional? You return errors if they aren't available. I think they are optional, the back-end might not support the operation. In this case, activating an RPMsg client that uses the interface should result in an error because the service is not compatible with the back-end implementation. Regards, Arnaud > >> * @create_ept: create backend-specific endpoint, required >> * @announce_create: announce presence of new channel, optional >> * @announce_destroy: announce destruction of channel, optional >> @@ -29,6 +31,11 @@ >> * advertise new channels implicitly by creating the endpoints. >> */ >> struct rpmsg_device_ops { >> + struct rpmsg_device *(*create_channel)(struct rpmsg_device *rpdev, >> + struct rpmsg_channel_info *chinfo); >> + int (*release_channel)(struct rpmsg_device *rpdev, >> + struct rpmsg_channel_info *chinfo); >> + >> struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev, >> rpmsg_rx_cb_t cb, void *priv, >> struct rpmsg_channel_info chinfo); >> @@ -75,6 +82,11 @@ int rpmsg_unregister_device(struct device *parent, >> struct device *rpmsg_find_device(struct device *parent, >> struct rpmsg_channel_info *chinfo); >> >> +struct rpmsg_device * >> +rpmsg_create_channel(struct rpmsg_device *rpdev, >> + struct rpmsg_channel_info *chinfo); >> +int rpmsg_release_channel(struct rpmsg_device *rpdev, >> + struct rpmsg_channel_info *chinfo); >> /** >> * rpmsg_chrdev_register_device() - register chrdev device based on rpdev >> * @rpdev: prepared rpdev to be used for creating endpoints >> -- >> 2.25.1 >>