Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp14243902pxu; Mon, 4 Jan 2021 17:37:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzwBvXx+F56IAXbmeIo2/bbZvFt72TBsC62wVX706n8edHWrdc+N+DlRKQgRK6E8PvWHGl3 X-Received: by 2002:a17:906:d0c1:: with SMTP id bq1mr62516522ejb.202.1609810634273; Mon, 04 Jan 2021 17:37:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609810634; cv=none; d=google.com; s=arc-20160816; b=VNKMhlTx2j08LefQ0Tyo5lVv2yWrr33dfH00jWfzzhAKJ4L+XiyOb2DpdXi+hv1jf+ +eHku626l7uK+UGsjlvRSA8uxAZcql5+wUidxKAPvlA2z5a48WtIf4aIj6AasiqQtM+N B5L8+Ojj854uCsxN+2/Y4EpAFY+KQOZ5+9Oad+YQUsC5GWS/p3Qol69Wp2jpvdyenWH9 neIJFuw7kpXMt8U6wNdfOxZwV5DCL5QfXzk1/XIJ2++sgYXAhArhRAty9lLEZixSwgn9 0B8DwewlKTfT9IfAeILUTGVMxfo9jTnG074kT/ztg1EaIDUZXQ1mVOw3tooZ3+3xKRF2 wDIQ== 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=YjjrmI1TJBpi7Irm0qGvA6ztJhR4MpSEaSWj5uIitYo=; b=SaS7p4dtE4YS3TlFsezXaadsWUNlHt7MF5Y0dcebbUxiyUTtlysQoTmhPAeKa7+Lbi 10EQYVCGymOvXdyfrm3JjyQ6M+1weAlIqq76itqWT+dFVRjGpJcGej4eRhhY1Za8jKiD X3BSXwLi7YfohLTL1+fgPsSXu88zvmkEeENiorz+1sJwNcmwDL1iYeChi2m+oFCOd35m qey5umaAJEG3srgEcp8+DfCDWdyaeRmrr4txilvW+iqvEWgjz4Xum4G/mXQ7HWpwGprO PhSNng9zKY+FNrqzyRloR6G7WQLcUy2ZWe8fMzeCRYK6IqYpDCiJR9jo/9uv07Ui1sj2 09PQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Di+a2AWD; 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 q6si33219303edn.416.2021.01.04.17.36.50; Mon, 04 Jan 2021 17:37:14 -0800 (PST) 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=Di+a2AWD; 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 S1727647AbhAEBeD (ORCPT + 99 others); Mon, 4 Jan 2021 20:34:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727556AbhAEBeD (ORCPT ); Mon, 4 Jan 2021 20:34:03 -0500 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6BBCC061794 for ; Mon, 4 Jan 2021 17:33:22 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id 15so34367813oix.8 for ; Mon, 04 Jan 2021 17:33:22 -0800 (PST) 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=YjjrmI1TJBpi7Irm0qGvA6ztJhR4MpSEaSWj5uIitYo=; b=Di+a2AWDW7bd7YL5Yy80WByU19A7SQge1qLnYyRquxiKeEe5mhx/0UUZzRsJ4r44gn P9MuPLf9UJxmhScHLeMqGpCdbc92Yp1WDrpmLh9wnBVvpFa9Y9qZ4Z04g7jP8cKFQ2tA wxgjt0cI1B0zWKZ4fb3pYdnfYC+H1I+oR+1agtcjXXZ5LAIXiB8YLpShQgOCr/iLV0Wq r4hBj7NRvT3SwP5Bd6WUYxrp8BOI+mv3EOZu8Bd719jcGXTlznSKH1m0FKn0hJHSR04h iasIhbhKOFUzIL+w0lLiM8pDgKLPiv3WXa3sVXVgn1g+VuxXpZGu66/MAJ/I6PPIa7nf q0Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YjjrmI1TJBpi7Irm0qGvA6ztJhR4MpSEaSWj5uIitYo=; b=OzncNkTcCA6FGoKxCL/g8/LZpS3aykA7UQT5ALhGMQF8c5u0vhYtSzISMRpiQcS+Y5 h0Eh99QC2nq6q8IITJaEB+0QUA2SflwL5APQBschq2seDlyswvqPoCCDGxSC7TEZuQTi ku1n0c16S8r1JcHYAf124kdC6MzajumW41yqpdeDdMiG21wiaNuqAXj54LzWvHTbCkv3 KOT0x9iXpAWG3u3h3oc+MB3gHpMAsx+HevPfd8naA5jNH0W3hN3ONysm/GopgonCtrrE i7aEYHknT7fpryLpRS/brCHR5JelRrRNocViw3I9RZ6q5bUWMBQkPeh25xYvF97jx+JZ YJ+A== X-Gm-Message-State: AOAM530Yy41xPvEtLjDW31coQpU2ssDSG5VRlJZ3cLlYMHeF/a1VfrgK 3REsS5tno2dKQ8vFR68XuD3oQQ== X-Received: by 2002:aca:7544:: with SMTP id q65mr1170662oic.51.1609810402083; Mon, 04 Jan 2021 17:33:22 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id n16sm13601112oov.23.2021.01.04.17.33.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Jan 2021 17:33:21 -0800 (PST) Date: Mon, 4 Jan 2021 19:33:19 -0600 From: Bjorn Andersson To: Arnaud Pouliquen Cc: Ohad Ben-Cohen , Mathieu Poirier , Andy Gross , 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 v2 04/16] rpmsg: ctrl: implement the ioctl function to create device Message-ID: References: <20201222105726.16906-1-arnaud.pouliquen@foss.st.com> <20201222105726.16906-5-arnaud.pouliquen@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201222105726.16906-5-arnaud.pouliquen@foss.st.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 22 Dec 04:57 CST 2020, 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 > --- > 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; > + } > + > + 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); Afaict this would create and announce and endpoint (or possibly find a endpoint announced by the other side of the link). In the case of the Qualcomm transports, and as been discussed to introduce for virtio in the past, the channel actually have a state. So opening/announcing it here means that we have no way to close and reopen this channel later? It would also mean that we announce to the firmware that there's an application in Linux now ready to receive data on this channel - but that won't be the case until someone actually open the created cdev (or tty in your case) - which quite likely will result in data loss. I think instead of piggybacking on the rpmsg_device we should just carry these "raw exports to userspace" in some other construct - perhaps a auxiliary_bus, or if we still only care for char and tty, not split them up at all using the device model. Regards, Bjorn > + if (!newch) { > + dev_err(&ctrldev->dev, "rpmsg_create_channel failed\n"); > + return -ENXIO; > + } > > return 0; > }; > -- > 2.17.1 >