On Sat, Nov 21, 2020 at 8:53 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Tue, 17 Nov 2020 18:23:28 +0200 > Alexandru Ardelean <alexandru.ardelean@xxxxxxxxxx> wrote: > > > Continuing from: > > https://lore.kernel.org/linux-iio/20200517144023.6c5cb169@archlinux/ > > > > This is a V2 of the initial attempt in the discussion above. > > But it did not occur to me that I should mark it as V2 when I generated > > the patches. > > I've only tested [so far] that the current IIO buffer mechnism still works. > > And decided to show this sketch patchset. > > > > This requires the ioctl() centralization mechanism, for which I sent a > > fix earlier. > > https://lore.kernel.org/linux-iio/CA+U=Dsqf3UgyM666Gg9EmehpWiucDx2P0bmsC9JR--JJDT_eWQ@xxxxxxxxxxxxxx/T/#t > > https://lore.kernel.org/linux-iio/20201117095154.7189-1-alexandru.ardelean@xxxxxxxxxx/T/#u > > > > The gist of this is that now, the first IIO buffer should work as > > before, but all extra buffers should go through the anon inodes > > mechanism. > > I'd need to find a device or a way or a chip to test these extra buffers > > stuff. But I'm confident that this current form should eventually work > > with multiple IIO buffers per 1 IIO device and with anon inodes. > > > > Maybe I'll take some of the patches in this set separately and send them > > individually. The problem with patchsets like this that tackle changes > > in a framework (like IIO) is that I become unsure after the 5th-7th patch, > > that the approach is correct. And I get even more unsure after that. > > > > I'll create some userspace code to test this a bit, but I thought I'd > > send an RFC in the meantime. > > From a first read, with all the warnings you give above, this looks pretty > good to me. The kobj stuff is a little nasty and needs more docs > but other than that it all looks quite pleasant and readable and was > roughly what I was expecting from earlier discussions (which is great!). > > Good work on this, looking forward to next steps. Thanks. I'll see about re-spinning this. With the iio_buffer_set_attrs() change merged, this patchset has a new context that I need to take a look at. > > Jonathan > > > > > Alexandru Ardelean (12): > > iio: core: register chardev only if needed > > iio: buffer: add back-ref from iio_buffer to iio_dev > > iio: buffer: rework buffer & scan_elements dir creation > > iio: buffer: add index to the first IIO buffer dir and symlink it back > > iio: core: split __iio_device_attr_init() to init only the attr object > > iio: buffer: re-route scan_elements via it's kobj_type > > iio: buffer: re-route core buffer attributes via it's new kobj_type > > iio: buffer: add helper to get the IIO device to which a buffer > > belongs > > iio: re-route all buffer attributes through new buffer kobj_type > > iio: core: wrap iio device & buffer into struct for character devices > > iio: buffer: introduce support for attaching more IIO buffers > > iio: buffer: add ioctl() to support opening extra buffers for IIO > > device > > > > drivers/iio/accel/adxl372.c | 36 +- > > drivers/iio/accel/bmc150-accel-core.c | 34 +- > > drivers/iio/adc/at91-sama5d2_adc.c | 30 +- > > .../buffer/industrialio-buffer-dmaengine.c | 13 +- > > .../cros_ec_sensors/cros_ec_sensors_core.c | 30 +- > > .../common/hid-sensors/hid-sensor-trigger.c | 32 +- > > drivers/iio/iio_core.h | 11 + > > drivers/iio/industrialio-buffer.c | 582 ++++++++++++++---- > > drivers/iio/industrialio-core.c | 117 ++-- > > include/linux/iio/buffer.h | 2 + > > include/linux/iio/buffer_impl.h | 25 +- > > include/linux/iio/iio-opaque.h | 6 + > > include/linux/iio/iio.h | 2 +- > > include/linux/iio/sysfs.h | 50 ++ > > include/uapi/linux/iio/buffer.h | 16 + > > 15 files changed, 735 insertions(+), 251 deletions(-) > > create mode 100644 include/uapi/linux/iio/buffer.h > > >
