summaryrefslogtreecommitdiffstats
path: root/drivers/iio/iio_core.h
Commit message (Collapse)AuthorAgeFilesLines
* iio: Remove unused declarationsYue Haibing2023-09-121-3/+0
| | | | | | | | | | | | | | | | | | Commit 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs") declared but never implemented iio_sw_device_type_configfs_{un}register(). Commit b662f809d410 ("iio: core: Introduce IIO software triggers") declared but never implemented iio_sw_trigger_type_configfs_{un}register(). Commit a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers") declared but never implemented fxls8962af_core_remove(). Commit 8dedcc3eee3a ("iio: core: centralize ioctl() calls to the main chardev") declared but never implemented iio_device_ioctl(). Commit d430f3c36ca6 ("iio: imu: inv_mpu6050: Use regmap instead of i2c specific functions") removed inv_mpu6050_write_reg() but not its declaration. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20230811095701.35372-1-yuehaibing@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: Mark iio_device_type as constLars-Peter Clausen2021-11-171-1/+1
| | | | | | | | | | The iio_device_type struct is never modified, mark it as const. This allows it to be placed in a read-only memory section, which will protect against accidental or deliberate modification. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211031080421.2086-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: Add output buffer supportMihail Chindris2021-10-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently IIO only supports buffer mode for capture devices like ADCs. Add support for buffered mode for output devices like DACs. The output buffer implementation is analogous to the input buffer implementation. Instead of using read() to get data from the buffer write() is used to copy data into the buffer. poll() with POLLOUT will wakeup if there is space available. Drivers can remove data from a buffer using iio_pop_from_buffer(), the function can e.g. called from a trigger handler to write the data to hardware. A buffer can only be either a output buffer or an input, but not both. So, for a device that has an ADC and DAC path, this will mean 2 IIO buffers (one for each direction). The direction of the buffer is decided by the new direction field of the iio_buffer struct and should be set after allocating and before registering it. Co-developed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Co-developed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-2-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: buffer: fix use-after-free for attached_buffers arrayAlexandru Ardelean2021-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Thanks to Lars for finding this. The free of the 'attached_buffers' array should be done as late as possible. This change moves it to iio_buffers_put(), which looks like the best place for it, since it takes place right before the IIO device data is free'd. The free of this array will be handled by calling iio_device_free(). The iio_buffers_put() function is renamed to iio_device_detach_buffers() since the role of this function changes a bit. It looks like this issue was ocurring on the error path of iio_buffers_alloc_sysfs_and_mask() and in iio_buffers_free_sysfs_and_mask() Added a comment in the doc-header of iio_device_attach_buffer() to mention how this will be free'd in case anyone is reading the code and becoming confused about it. Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210307185444.32924-1-ardeleanalex@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: buffer: add ioctl() to support opening extra buffers for IIO deviceAlexandru Ardelean2021-03-111-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, an ioctl() call is added to open a character device for a buffer. The ioctl() number is 'i' 0x91, which follows the IIO_GET_EVENT_FD_IOCTL ioctl. The ioctl() will return an FD for the requested buffer index. The indexes are the same from the /sys/iio/devices/iio:deviceX/bufferY (i.e. the Y variable). Since there doesn't seem to be a sane way to return the FD for buffer0 to be the same FD for the /dev/iio:deviceX, this ioctl() will return another FD for buffer0 (or the first buffer). This duplicate FD will be able to access the same buffer object (for buffer0) as accessing directly the /dev/iio:deviceX chardev. Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl() implemented, as the index for each buffer (and the count) can be deduced from the '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the number of bufferY folders). Used following C code to test this: ------------------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/ioctl.h> #include <fcntl.h" #include <errno.h> #define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int) int main(int argc, char *argv[]) { int fd; int fd1; int ret; if ((fd = open("/dev/iio:device0", O_RDWR))<0) { fprintf(stderr, "Error open() %d errno %d\n",fd, errno); return -1; } fprintf(stderr, "Using FD %d\n", fd); fd1 = atoi(argv[1]); ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, &fd1); if (ret < 0) { fprintf(stderr, "Error for buffer %d ioctl() %d errno %d\n", fd1, ret, errno); close(fd); return -1; } fprintf(stderr, "Got FD %d\n", fd1); close(fd1); close(fd); return 0; } ------------------------------------------------------------------- Results are: ------------------------------------------------------------------- # ./test 0 Using FD 3 Got FD 4 # ./test 1 Using FD 3 Got FD 4 # ./test 2 Using FD 3 Got FD 4 # ./test 3 Using FD 3 Got FD 4 # ls /sys/bus/iio/devices/iio\:device0 buffer buffer0 buffer1 buffer2 buffer3 dev in_voltage_sampling_frequency in_voltage_scale in_voltage_scale_available name of_node power scan_elements subsystem uevent ------------------------------------------------------------------- iio:device0 has some fake kfifo buffers attached to an IIO device. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-21-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: buffer: introduce support for attaching more IIO buffersAlexandru Ardelean2021-03-111-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, calling iio_device_attach_buffer() will actually attach more buffers. Right now this doesn't do any validation of whether a buffer is attached twice; maybe that can be added later (if needed). Attaching a buffer more than once should yield noticeably bad results. The first buffer is the legacy buffer, so a reference is kept to it. At this point, accessing the data for the extra buffers (that are added after the first one) isn't possible yet. The iio_device_attach_buffer() is also changed to return an error code, which for now is -ENOMEM if the array could not be realloc-ed for more buffers. To adapt to this new change iio_device_attach_buffer() is called last in all place where it's called. The realloc failure is a bit difficult to handle during un-managed calls when unwinding, so it's better to have this as the last error in the setup_buffer calls. At this point, no driver should call iio_device_attach_buffer() directly, it should call one of the {devm_}iio_triggered_buffer_setup() or devm_iio_kfifo_buffer_setup() or devm_iio_dmaengine_buffer_setup() functions. This makes iio_device_attach_buffer() a bit easier to handle. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-20-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: core: wrap iio device & buffer into struct for character devicesAlexandru Ardelean2021-03-111-0/+5
| | | | | | | | | | | | | | | | | In order to keep backwards compatibility with the current chardev mechanism, and in order to add support for multiple buffers per IIO device, we need to pass both the IIO device & IIO buffer to the chardev. This is particularly needed for the iio_buffer_read_outer() function, where we need to pass another buffer object than 'indio_dev->buffer'. Since we'll also open some chardevs via anon inodes, we can pass extra buffers in that function by assigning another object to the iio_dev_buffer_pair object. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-17-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: add reference to iio buffer on iio_dev_attrAlexandru Ardelean2021-03-111-0/+2
| | | | | | | | | | | | | | This change adds a reference to a 'struct iio_buffer' object on the iio_dev_attr object. This way, we can use the created iio_dev_attr objects on per-buffer basis (since they're allocated anyway). A minor downside of this change is that the number of parameters on __iio_add_chan_devattr() grows by 1. This looks like it could do with a bit of a re-think. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-14-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: core: rework iio device group creationAlexandru Ardelean2021-03-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now, the device groups that an IIO device had were limited to 6. Two of these groups would account for buffer attributes (the buffer/ and scan_elements/ directories). Since we want to add multiple buffers per IIO device, this number may not be enough, when adding a second buffer. So, this change reallocates the groups array whenever an IIO device group is added, via a iio_device_register_sysfs_group() helper. This also means that the groups array should be assigned to 'indio_dev.dev.groups' really late, right before {cdev_}device_add() is called to do the entire setup. And we also must take care to free this array when the sysfs resources are being cleaned up. With this change we can also move the 'groups' & 'groupcounter' fields to the iio_dev_opaque object. Up until now, this didn't make a whole lot of sense (especially since we weren't sure how multibuffer support would look like in the end). But doing it now kills one birds with one stone. An alternative, would be to add a configurable Kconfig symbol CONFIG_IIO_MAX_BUFFERS_PER_DEVICE (or something like that) and compute a static maximum of the groups we can support per IIO device. But that would probably annoy a few people since that would make the system less configurable. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-11-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: core: centralize ioctl() calls to the main chardevAlexandru Ardelean2020-11-141-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The aim of this is to improve a bit the organization of ioctl() calls in IIO core. Currently the chardev is split across IIO core sub-modules/files. The main chardev has to be able to handle ioctl() calls, and if we need to add buffer ioctl() calls, this would complicate things. The 'industrialio-core.c' file will provide a 'iio_device_ioctl()' which will iterate over a list of ioctls registered with the IIO device. These can be event ioctl() or buffer ioctl() calls, or something else. Each ioctl() handler will have to return a IIO_IOCTL_UNHANDLED code (which is positive 1), if the ioctl() did not handle the call in any. This eliminates any potential ambiguities about negative error codes, which should fail the call altogether. If any ioctl() returns 0, it was considered that it was serviced successfully and the loop will exit. This change also moves the handling of the IIO_GET_EVENT_FD_IOCTL command inside 'industrialio-event.c', where this is better suited. This patch is a combination of 2 other patches from an older series: Patch 1: iio: core: add simple centralized mechanism for ioctl() handlers Link: https://lore.kernel.org/linux-iio/20200427131100.50845-6-alexandru.ardelean@analog.com/ Patch 2: iio: core: use new common ioctl() mechanism Link: https://lore.kernel.org/linux-iio/20200427131100.50845-7-alexandru.ardelean@analog.com/ Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200924084155.99406-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* iio: buffer: rename 'read_first_n' callback to 'read'Lars-Peter Clausen2019-12-291-4/+4
| | | | | | | | | | | | | It is implied that 'read' will read the first n bytes and not e.g. bytes only from offsets within the buffer that are a prime number. This change is non-functional, mostly just a rename. A secondary intent with this patch is to make room later to add a write callback. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* the rest of drivers/*: annotate ->poll() instancesAl Viro2017-11-281-1/+1
| | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* iio:core: timestamping clock selection supportGregor Boirie2016-06-301-0/+3
| | | | | | | | | | | | | | | Adds a new per-device sysfs attribute "current_timestamp_clock" to allow userspace to select a particular POSIX clock for buffered samples and events timestamping. Following clocks, as listed in clock_gettime(2), are supported: CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Acked-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Move buffer registration to the coreLars-Peter Clausen2014-12-121-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Originally device and buffer registration were kept as separate operations in IIO to allow to register two distinct sets of channels for buffered and non-buffered operations. This has since already been further restricted and the channel set registered for the buffer needs to be a subset of the channel set registered for the device. Additionally the possibility to not have a raw (or processed) attribute for a channel which was registered for the device was added a while ago. This means it is possible to not register any device level attributes for a channel even if it is registered for the device. Also if a channel's scan_index is set to -1 and the channel is registered for the buffer it is ignored. So in summary it means it is possible to register the same channel array for both the device and the buffer yet still end up with distinctive sets of channels for both of them. This makes the argument for having to have to manually register the channels for both the device and the buffer invalid. Considering that the vast majority of all drivers want to register the same set of channels for both the buffer and the device it makes sense to move the buffer registration into the core to avoid some boiler-plate code in the device driver setup path. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* IIO: core: Introduce read_raw_multiSrinivas Pandruvada2014-04-291-1/+1
| | | | | | | | | | | | | | This callback is introduced to overcome some limitations of existing read_raw callback. The functionality of both existing read_raw and read_raw_multi is similar, both are used to request values from the device. The current read_raw callback allows only two return values. The new read_raw_multi allows returning multiple values. Instead of passing just address of val and val2, it passes length and pointer to values. Depending on the type and length of passed buffer, iio client drivers can return multiple values. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Factor IIO value formating into its own functionLars-Peter Clausen2013-10-121-0/+2
| | | | | Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Add a helper to free a list of IIO device attributesLars-Peter Clausen2013-10-121-0/+1
| | | | | | | | | | | We have the same code to free a IIO device attribute list in multiple place. This patch adds a new helper function to take care of this and replaces the custom instances with a call to the helper function. Note that we do not need to call list_del() for each of the list items since we will never look at any of the list items nor the list itself again. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Wakeup poll and blocking reads when the device is unregisteredLars-Peter Clausen2013-10-121-0/+3
| | | | | | | | | Once the device has been unregistered there won't be any new data no matter how long a userspace application waits, so we might as well wake them up and let them know. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* Merge 3.12-rc2 into staging-next.Greg Kroah-Hartman2013-09-251-0/+4
|\ | | | | | | | | | | | | | | This resolves the merge problem with two iio drivers that Stephen Rothwell pointed out. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * iio: Stop sampling when the device is removedLars-Peter Clausen2013-09-211-0/+4
| | | | | | | | | | | | | | | | Make sure to stop sampling when the device is removed, otherwise it will continue to sample forever. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | iio: refactor info mask and ext_info attribute creation.Jonathan Cameron2013-09-151-1/+1
|/ | | | | | | | | | | | | | | | Introduce an enum to specify whether the attribute is separate or shared. Factor out the bitmap handling for loop into a separate function. Tidy up error handling and add a NULL assignment to squish a false positive warning from GCC. Change ext_info shared type from boolean to enum and update in all drivers. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
* iio: Add OF supportGuenter Roeck2013-03-161-0/+1
| | | | | | | | Provide bindings and parse OF data during initialization. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* IIO: Move the core files to drivers/iioJonathan Cameron2012-04-251-0/+62
Take the core support + the kfifo buffer implentation out of staging. Whilst we are far from done in improving this subsystem it is now at a stage where the userspae interfaces (provided by the core) can be considered stable. Drivers will follow over a longer time scale. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>