Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2731588pxb; Sun, 28 Feb 2021 11:11:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfxNx8VutguJGZw/SygHeQFAbVSvLFOkQ0zR2N9koEZVf+l+QyaA11n2A93A/Qlppiqxq5 X-Received: by 2002:a05:6402:32d:: with SMTP id q13mr4697639edw.17.1614539516932; Sun, 28 Feb 2021 11:11:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614539516; cv=none; d=google.com; s=arc-20160816; b=a2Ijr1rBK7vpKYk9/CdpcHjTUgBHmWN581Ip8wDn8G06a6y7hDrPGZpNH+ziN85uRI cBfKLX6D3BC6jfndfGsDVGzeyYgQ1ZvOAaBifRB1fhY/zupp108Nfwlc4pqi/3C0G3+B LyZ/003IXGJ8maQuE0CoK4N3apmbE3OhIdZ9dKNnBF+JpiXXC9XG5FhOlyUok4jCkMWP bFPXjMdPyUKqwP2CTbcXLMyGJCm0W+1OG4GUWj6X92KZueq8FI+mlnqEW+AS8fpY6jzN r7Q8UijCCXL2tYRGvgQ5ZED+kJ7GAi4vhecv0YDHl2mRPGHFpZ/YoXbK/J1kafGUEnfA IFdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=xTiJ+SSPzsh7FFfy/EXsqQv5iHSzQI6Qmwot/3GX6qo=; b=J7NAqw5in04idWRZT4rQUFAuVEVXDZRCZBH1pf/KdZ2nfhn1hYGK09EaK8KqnETYAn YCs40SZ1loHoQe110anQUorGOBNL0bNAzzrkvNlR5pB0F09YmH4pFNvt1z7FnfeorZD3 fMsSMVzthbTnr5163QZQ/NZwIIjwqpnc6SuV/IMFPcd5ot+wKN/L7WR3RVPYJGH1eT71 sVwTxHzrM1OGOH61Pp5+egG/r/iu6H+jBEzTsLFrf5xVtItCXi/sD1ClXwrmYPm5CLdJ Buwtbgb+Y1JBfbkvGf8nE5iG0Cw5W9SZS5GxNgYLXxmspfFjOE8Bt545tkC0LfqKr3Dv 8/Bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TKTjpSoZ; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k2si10211537ejr.529.2021.02.28.11.11.34; Sun, 28 Feb 2021 11:11:56 -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=@gmail.com header.s=20161025 header.b=TKTjpSoZ; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231384AbhB1SFk (ORCPT + 99 others); Sun, 28 Feb 2021 13:05:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231295AbhB1SFj (ORCPT ); Sun, 28 Feb 2021 13:05:39 -0500 Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 875B4C06174A; Sun, 28 Feb 2021 10:04:58 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id g9so12694815ilc.3; Sun, 28 Feb 2021 10:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xTiJ+SSPzsh7FFfy/EXsqQv5iHSzQI6Qmwot/3GX6qo=; b=TKTjpSoZGt8vOzS7Yocmq/ZEOtJCObqU+JvvM1hp024NKuCyNN5tKOiJ3k474pQhuN fx3cbHEsH9iVZ6KYistXDNiXD4AZJQAPNsxIeGe45X9BQLwWA9O3KQ+5i5NDJKuPl6HR lOsVvZYCGf1C3Gg0jZuVQupoixWMtlvZS5ikJ3Mi+5RIQYsTujsxjJM02Mq3zNLRbZmQ iol+YpWGGsVyjGdQo0HFYWpXiBZkRGQ6XJG2FKOiFjBbyF4ezHTo77I1UJAdVHITA5qm Gkvo4tvNDqPkCFj/dFqdw3n6qHHoAcfO2vD8Z8LT40Muw66mhovtd6efiHGpgW5TVDpF Bz5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xTiJ+SSPzsh7FFfy/EXsqQv5iHSzQI6Qmwot/3GX6qo=; b=GydbrZ8Uk8uCKLua+mRsYqo4muhFaT7eqEZoaIps6ZaKUlrH6Abs8LCyn1X1wIi4df zuyWQBnX6syOHQVRE7a4D7zeqhUdSXaWh0YoC/WsGy94eFdA3WWbiz4TVf1p5SJWAThN 2gBFUwPaW+IZNurTTY50FLQFhToJ7NyAPhiKC3GEWt4zTqSHwU7xSxj+HKBx49E+VfOo Jpfj20lENy8Tkvyk+KVbOpWdXGgVcocoEsI2cbixLCsvoDlsbT5rx52Di9vUNpO8Nx8K qeY1X/Jw8ws9LhklwfnasShAN1IaYF8zX40v3EcLCySUR8Tj062dO4q5n85Rdmtfgowu 8AhA== X-Gm-Message-State: AOAM530GRpz38w8lQ3vIbJL1DQPt2QQcsyTn8fKxizGuE4km+yvkiThR 5wZzcjlspCTXNlz0VPCvsukDS7T74IjIvjNizaI= X-Received: by 2002:a92:d0c3:: with SMTP id y3mr10108711ila.303.1614535497737; Sun, 28 Feb 2021 10:04:57 -0800 (PST) MIME-Version: 1.0 References: <20210215104043.91251-1-alexandru.ardelean@analog.com> <20210215104043.91251-21-alexandru.ardelean@analog.com> In-Reply-To: From: Alexandru Ardelean Date: Sun, 28 Feb 2021 20:04:45 +0200 Message-ID: Subject: Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support opening extra buffers for IIO device To: Lars-Peter Clausen Cc: Alexandru Ardelean , LKML , linux-iio , "Hennerich, Michael" , Jonathan Cameron , =?UTF-8?B?TnVubyBTw6E=?= , "Bogdan, Dragos" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 28, 2021 at 9:58 AM Lars-Peter Clausen wrote: > > On 2/15/21 11:40 AM, Alexandru Ardelean wrote: > > [...] > > /** > > * iio_buffer_wakeup_poll - Wakes up the buffer waitqueue > > * @indio_dev: The IIO device > > @@ -1343,6 +1371,96 @@ static void iio_buffer_unregister_legacy_sysfs_groups(struct iio_dev *indio_dev) > > kfree(iio_dev_opaque->legacy_scan_el_group.attrs); > > } > > > > [...] > > +static long iio_device_buffer_getfd(struct iio_dev *indio_dev, unsigned long arg) > > +{ > > + struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev); > > + int __user *ival = (int __user *)arg; > > + struct iio_dev_buffer_pair *ib; > > + struct iio_buffer *buffer; > > + int fd, idx, ret; > > + > > + if (copy_from_user(&idx, ival, sizeof(idx))) > > + return -EFAULT; > > If we only want to pass an int, we can pass that directly, no need to > pass it as a pointer. > > int fd = arg; I guess I can simplify this a bit. > > > + > > + if (idx >= iio_dev_opaque->attached_buffers_cnt) > > + return -ENODEV; > > + > > + iio_device_get(indio_dev); > > + > > + buffer = iio_dev_opaque->attached_buffers[idx]; > > + > > + if (test_and_set_bit(IIO_BUSY_BIT_POS, &buffer->flags)) { > > + ret = -EBUSY; > > + goto error_iio_dev_put; > > + } > > + > > + ib = kzalloc(sizeof(*ib), GFP_KERNEL); > > + if (!ib) { > > + ret = -ENOMEM; > > + goto error_clear_busy_bit; > > + } > > + > > + ib->indio_dev = indio_dev; > > + ib->buffer = buffer; > > + > > + fd = anon_inode_getfd("iio:buffer", &iio_buffer_chrdev_fileops, > > + ib, O_RDWR | O_CLOEXEC); > > I wonder if we need to allow to pass flags, like e.g. O_NONBLOCK. > > Something like > https://elixir.bootlin.com/linux/latest/source/fs/signalfd.c#L288 Umm, no idea. I guess we could. Would a syscall make more sense than an ioctl() here? I guess for the ioctl() case we would need to change the type (of the data) to some sort of struct iio_buffer_get_fd { unsigned int buffer_idx; unsigned int fd_flags; }; Or do we just let userspace use fcntl() to change flags to O_NONBLOCK ? > > > + if (fd < 0) { > > + ret = fd; > > + goto error_free_ib; > > + } > > + > > + if (copy_to_user(ival, &fd, sizeof(fd))) { > > + put_unused_fd(fd); > > + ret = -EFAULT; > > + goto error_free_ib; > > + } > > Here we copy back the fd, but also return it. Just return is probably > enough. Hmm. Yes, it is a bit duplicate. But it is a good point. Maybe we should return 0 to userspace. > > > + > > + return fd; > > + > > +error_free_ib: > > + kfree(ib); > > +error_clear_busy_bit: > > + clear_bit(IIO_BUSY_BIT_POS, &buffer->flags); > > +error_iio_dev_put: > > + iio_device_put(indio_dev); > > + return ret; > > +} > > [...] > > diff --git a/include/linux/iio/iio-opaque.h b/include/linux/iio/iio-opaque.h > > index b6ebc04af3e7..32addd5e790e 100644 > > --- a/include/linux/iio/iio-opaque.h > > +++ b/include/linux/iio/iio-opaque.h > > @@ -9,6 +9,7 @@ > > * @event_interface: event chrdevs associated with interrupt lines > > * @attached_buffers: array of buffers statically attached by the driver > > * @attached_buffers_cnt: number of buffers in the array of statically attached buffers > > + * @buffer_ioctl_handler: ioctl() handler for this IIO device's buffer interface > > * @buffer_list: list of all buffers currently attached > > * @channel_attr_list: keep track of automatically created channel > > * attributes > > @@ -28,6 +29,7 @@ struct iio_dev_opaque { > > struct iio_event_interface *event_interface; > > struct iio_buffer **attached_buffers; > > unsigned int attached_buffers_cnt; > > + struct iio_ioctl_handler *buffer_ioctl_handler; > > Can we just embedded this struct so we do not have to > allocate/deallocate it? Unfortunately we can't. The type of ' struct iio_ioctl_handler ' is stored in iio_core.h. So, we don't know the size here. So we need to keep it as a pointer and allocate it. It is a bit of an unfortunate consequence of the design of this generic ioctl() registering. > > > struct list_head buffer_list; > > struct list_head channel_attr_list; > > struct attribute_group chan_attr_group; > >