summaryrefslogtreecommitdiff
path: root/drivers/iio/industrialio-core.c
AgeCommit message (Collapse)Author
2022-06-15iio: Use octal permissions and DEVICE_ATTR_{RO,RW}.Joe Simmons-Talbott
As reported by checkpatch.pl. Where possible use DEVICE_ATTR_RO(), DEVICE_ATTR_RW(), and __ATTR_RO(). Change function names to be <var>_show() for read and <var>_store() for write. Suggested-by: Joe Perches <joe@perches.com> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Joe Simmons-Talbott <joetalbott@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220601185414.251571-1-joetalbott@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-06-14iio: core: Fix IIO_ALIGN and rename as it was not sufficiently largeJonathan Cameron
Discussion of the series: https://lore.kernel.org/all/20220405135758.774016-1-catalin.marinas@arm.com/ mm, arm64: Reduce ARCH_KMALLOC_MINALIGN brought to my attention that our current IIO usage of L1CACHE_ALIGN is insufficient as their are Arm platforms out their with non coherent DMA and larger cache lines at at higher levels of their cache hierarchy. Rename the define to make it's purpose more explicit. It will be used much more widely going forwards (to replace incorrect ____cacheline_aligned markings. Note this patch will greatly reduce the padding on some architectures that have smaller requirements for DMA safe buffers. The history of changing values of ARCH_KMALLOC_MINALIGN via ARCH_DMA_MINALIGN on arm64 is rather complex. I'm not tagging this as fixing a particular patch from that route as it's not clear what to tag. Most recently a change to bring them back inline was reverted because of some Qualcomm Kryo cores with an L2 cache with 128-byte lines sitting above the point of coherency. c1132702c71f Revert "arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)" That reverts: 65688d2a05de arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES) which refers to the change originally being motivated by Thunder x1 performance rather than correctness. Fixes: 6f7c8ee585e9d ("staging:iio: Add ability to allocate private data space to iio_allocate_device") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-2-jic23@kernel.org
2022-06-14iio: core: drop iio_get_time_res()Jonathan Cameron
This function was introduced with the ability to pick a clock. There are no upstream users so presumably it isn't as obviously useful as it seemed at the time. Hence drop it. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20220220163327.424696-1-jic23@kernel.org
2022-06-11iio: Directly use ida_alloc()/free()keliu
Use ida_alloc()/ida_free() instead of deprecated ida_simple_get()/ida_simple_remove() . Signed-off-by: keliu <liuke94@huawei.com> Link: https://lore.kernel.org/r/20220527091739.2949426-1-liuke94@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-28iio: core: Convert to use firmware node handle instead of OF nodeAndy Shevchenko
Switch the IIO core to use firmware node handle instead of OF node. This will allow to get label from firmware on non-OF systems. Note, this doesn't change of_iio_*() APIs for now. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220413180202.19220-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: core: Move the currentmode entry to the opaque structureMiquel Raynal
This entry should, under no situation, be modified by device drivers. Now that we have limited its read access to device drivers really needing it and did so through a dedicated helper, we can easily move this variable to the opaque structure in order to prevent any further modification from non-authorized code (out of the core, basically). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20220207143840.707510-12-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: core: Hide read accesses to iio_dev->currentmodeMiquel Raynal
In order to later move this variable within the opaque structure, let's create a helper for accessing it in read-only mode. This helper will be exposed to device drivers and kept accessible for the few that could need it. The write access to this variable however should be fully reserved to the core so in a second step we will hide this variable into the opaque structure. Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-11-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: Un-inline iio_buffer_enabled()Miquel Raynal
As we are going to hide the currentmode inside the opaque structure, this helper would soon need to call a non-inline function which would simply drop the benefit of having the helper defined inline in a header. One alternative is to move this helper in the core as there is no more interest in defining it inline in a header. We will pay the minor cost either way. Let's do like the iio_device_id() helper which also refers to the opaque structure and gets defined in the core. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-10-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: core: fix a few code style issuesAlexander Vorwerk
* Fix indent in else statement * Remove unnecessary 'else' after 'break' * Remove space in '* attr' Signed-off-by: Alexander Vorwerk <alexander.vorwerk@stud.uni-goettingen.de> Link: https://lore.kernel.org/r/20220312180343.8935-1-alexander.vorwerk@stud.uni-goettingen.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-01-23iio: core: Use sysfs_emit()Lars-Peter Clausen
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it knows about the sysfs buffer specifics and has some built-in checks for size and alignment. This patch converts the places in the IIO core that follow the pattern of return s*printf(...) to return sysfs_emit(...) This covers the new places that have been introduced where sprintf() is used for formatting sysfs output since the last time this was done in commit 83ca56b663cf ("iio: core: Use sysfs_emit() (trivial bits)"). Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211216185217.1054495-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-12-16iio: iio_device_alloc(): Remove unnecessary self drvdataLars-Peter Clausen
Drvdata is typically used by drivers to attach driver specific data to a device. It is used to retrieve driver specific information when only the device to which the data is attached is available. In the IIO core in the `iio_device_alloc()` function we call `iio_device_set_drvdata(indio_dev, indio_dev)`. This sets the drvdata of the IIO device to itself. This is rather unnecessary since if we have a pointer to the IIO device to call `iio_device_get_drvdata()` on it we don't need to call the function since we already have the pointer. If we only have a pointer to the `struct device` we can use `dev_to_iio_dev()` to get the IIO device from it. Furthermore the drvdata is supposed to be reserved for drivers, so it should not be used by the IIO core in the first place. The `set_drvdata()` has been around from the very beginning of the IIO framework and back then it was used in the IIO device sysfs attribute handling code. But that was subsequently replaced with a `dev_to_iio_dev()` in commit e53f5ac52ec1 ("iio: Use dev_to_iio_dev()") and other cleanups. The self `set_drvdata()` is now no longer needed and can be removed. Verified that there no longer any users by checking for potential users using the following two coccinelle scripts and reviewing that none of the matches are problematic code. <smpl> @@ struct iio_dev *iio_dev; expression dev; identifier fn !~ "(remove|resume|suspend)"; @@ fn(...) { ... *iio_dev = dev_get_drvdata(dev) ... } </smpl> <smpl> @r1@ position p; struct iio_dev *indio_dev; identifier dev_fn =~ "^dev_"; identifier devm_fn =~ "^devm_"; @@ ( dev_fn | devm_fn ) (&indio_dev@p->dev, ...) @@ struct iio_dev *indio_dev; position p != r1.p; @@ *&indio_dev@p->dev</smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-11-17iio: Mark iio_device_type as constLars-Peter Clausen
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>
2021-11-17iio: core: Introduce IIO_VAL_INT_64.Andriy Tryshnivskyy
Introduce IIO_VAL_INT_64 to read 64-bit value for channel attribute. Val is used as lower 32 bits. Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Link: https://lore.kernel.org/r/20211024091627.28031-2-andriy.tryshnivskyy@opensynergy.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-24Merge tag 'iio-fixes-for-5.16a' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: First set of IIO fixes for the 5.16 cycle As these are very late in the 5.15 cycle and non are particularly urgent, they can wait for the merge window. Key element in this set is Yang Yingliang has identified a number of issues in error paths introduced recently when we added multiple buffer support. Other fixes: * adi,ad5662 - Fix handling of i2c_master_send() return value. * adi,ad5766 - Fix a wrong dt-property name that indicated wrong units and did not mach the bindings. - Associated 'fix' of the bindings example to have a possible scale. * st,pressure-spi - Add some missing entries to the spi_device_id table to ensure auto-loading works. * ti,tsc2046 - Fix a backwards comparison leading to a false dev_warn * tag 'iio-fixes-for-5.16a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: buffer: Fix memory leak in iio_buffers_alloc_sysfs_and_mask() iio: adc: tsc2046: fix scan interval warning iio: core: fix double free in iio_device_unregister_sysfs() iio: core: check return value when calling dev_set_name() iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups() iio: buffer: Fix double-free in iio_buffers_alloc_sysfs_and_mask() iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask() iio: buffer: check return value of kstrdup_const() iio: dac: ad5446: Fix ad5622_write() return value Documentation:devicetree:bindings:iio:dac: Fix val drivers: iio: dac: ad5766: Fix dt property name iio: st_pressure_spi: Add missing entries SPI to device ID table
2021-10-19iio: Add output buffer supportMihail Chindris
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>
2021-10-17iio: core: fix double free in iio_device_unregister_sysfs()Yang Yingliang
I got the double free report: BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 iio_device_unregister_sysfs+0x108/0x13b [industrialio] iio_dev_release+0x9e/0x10e [industrialio] device_release+0xa5/0x240 If __iio_device_register() fails, iio_dev_opaque->groups will be freed in error path in iio_device_unregister_sysfs(), then iio_dev_release() will call iio_device_unregister_sysfs() again, it causes double free. Set iio_dev_opaque->groups to NULL when it's freed to fix this double free. Not this is a local work around for a more general mess around life time management that will get cleaned up and should make this handling unnecesarry. Fixes: 32f171724e5c ("iio: core: rework iio device group creation") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: core: check return value when calling dev_set_name()Yang Yingliang
I got a null-ptr-deref report when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: start_creating+0x199/0x2f0 debugfs_create_dir+0x25/0x430 __iio_device_register+0x4da/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] max1027_probe+0x639/0x860 [max1027] spi_probe+0x183/0x210 really_probe+0x285/0xc30 If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support...") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211012063624.3167460-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: core: Support reading extended name as labelPaul Cercueil
The point of this new change is to make the IIO tree actually parsable. Before, given this attribute as a filename: in_voltage0_aux_sample_rate Userspace had no way to know if the attribute name was "aux_sample_rate" with no extended name, or "sample_rate" with "aux" as the extended name, or just "rate" with "aux_sample" as the extended name. This was somewhat possible to deduce when there was more than one attribute present for a given channel, e.g: in_voltage0_aux_sample_rate in_voltage0_aux_frequency There, it was possible to deduce that "aux" was the extended name. But even with more than one attribute, this wasn't very robust, as two attributes starting with the same prefix (e.g. "sample_rate" and "sample_size") would result in the first part of the prefix being interpreted as being part of the extended name. To address the issue, knowing that channels will never have both a label and an extended name, set the channel's label to the extended name. In this case, the label's attribute will also have the extended name in its filename, but we can live with that - userspace can open in_voltage0_<prefix>_label and verify that it returns <prefix> to obtain the extended name. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: core: Forbid use of both labels and extended namesPaul Cercueil
Extended names are a problem for user-space as they make the filenames in sysfs sometimes not parsable. They are now deprecated in favor of labels. This change makes sure that a device driver won't provide both labels and extended names for its channels. It has never been the case and we don't want it to happen. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-03iio: Drop Duplicated "mount-matrix" parameterAndy Shevchenko
All of the users of iio_read_mount_matrix() are using the very same property name. Moreover, the property name is hard coded in the API documentation. Make this clear and avoid duplication now and in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210518112546.44592-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-05-17iio: core: Fix an error pointer vs NULL bug in devm_iio_device_alloc()Dan Carpenter
The devm_iio_device_alloc() function is supposed to return NULL and not error pointers. Returning an error pointer will lead to a crash in the callers. Fixes: cf5724e91515 ("iio: core: simplify some devm functions") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/YJ+a1yaMu2QNATgt@mwanda Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-05-17iio: core: move @clock_id from struct iio_dev to struct iio_dev_opaqueJonathan Cameron
There is already an acessor function used to access it, making this move straight forward. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-10-jic23@kernel.org
2021-05-17iio: core: move @flags from struct iio_dev to struct iio_dev_opaqueJonathan Cameron
No reason any driver should ever need access to this field, so hide it. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-9-jic23@kernel.org
2021-05-17iio: core: move @chrdev from struct iio_dev to struct iio_dev_opaqueJonathan Cameron
No reason for this to be exposed to the drivers, so lets move it to the opaque structure. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-8-jic23@kernel.org
2021-05-17iio: core: move @info_exist_lock to struct iio_dev_opaqueJonathan Cameron
This lock is only of interest to the IIO core, so make it only visible there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-7-jic23@kernel.org
2021-05-17iio: core: move @driver_module from struct iio_dev to struct iio_dev_opaqueJonathan Cameron
Continuing move to hide internal elements from drivers, move this structure element over. It's only accessed from iio core files so this one was straight forward and no accessor functions are needed. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-4-jic23@kernel.org
2021-05-17iio: core: move @id from struct iio_dev to struct iio_dev_opaqueJonathan Cameron
Continuing from Alexandru Ardelean's introduction of the split between driver modifiable fields and those that should only be set by the core. This could have been done in two steps to make the actual move after introducing iio_device_id() but there seemed limited point to that given how mechanical the majority of the patch is. Includes fixup from Alex for missing mxs-lradc-adc conversion. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org
2021-05-17iio: core: simplify some devm functionsYicong Yang
Use devm_add_action_or_reset() instead of devres_alloc() and devres_add(), which works the same. This will simplify the code. There is no functional changes. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-6-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-05-10iio: core: return ENODEV if ioctl is unknownAlexandru Ardelean
When the ioctl() mechanism was introduced in IIO core to centralize the registration of all ioctls in one place via commit 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev"), the return code was changed from ENODEV to EINVAL, when the ioctl code isn't known. This was done by accident. This change reverts back to the old behavior, where if the ioctl() code isn't known, ENODEV is returned (vs EINVAL). This was brought into perspective by this patch: https://lore.kernel.org/linux-iio/20210428150815.136150-1-paul@crapouillou.net/ Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev") Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-05-10iio: core: fix ioctl handlers removalTomasz Duszynski
Currently ioctl handlers are removed twice. For the first time during iio_device_unregister() then later on inside iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask(). Double free leads to kernel panic. Fix this by not touching ioctl handlers list directly but rather letting code responsible for registration call the matching cleanup routine itself. Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev") Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Acked-by: Alexandru Ardelean <ardeleanalex@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210423080244.2790-1-tomasz.duszynski@octakon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-29iio: __iio_format_value(): Convert to sysfs_emit_at()Lars-Peter Clausen
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it knows about the sysfs buffer specifics and has some built-in sanity checks. Convert __iio_format_value() and related functions to use this new interface. This conversion involves changing the signature of __iio_format_value() so that it similar to sysfs_emit_at() and takes the buffers start address and an offset where to write within the buffer. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20210320071405.9347-4-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-29iio: iio_enum_available_read(): Convert to sysfs_emit_at()Lars-Peter Clausen
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it knows about the sysfs buffer specifics and has some built-in sanity checks. Convert the iio_enum_available_read() function to use sysfs_emit_at() instead of scnprintf(). The conversion is straight forward, the only difference is that sysfs_emit_at() takes the buffers start address and an offset as parameters and already knows about the buffer's size limit. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20210320071405.9347-3-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-29iio: core: Use sysfs_emit() (trivial bits)Lars-Peter Clausen
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it knows about the sysfs buffer specifics and has some built-in sanity checks. This patch converts the places in the iio core that follow the pattern of return s*printf(...) to return sysfs_emit(...) Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20210320071405.9347-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25iio: buffer: fix use-after-free for attached_buffers arrayAlexandru Ardelean
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>
2021-03-11iio: Add relative sensitivity supportYe Xiang
Some hid sensors may use relative sensitivity such as als sensor. This patch adds relative sensitivity checking for all hid sensors. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20210207070048.23935-2-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: use getter/setter functionsJulia Lawall
Use getter and setter functions, for a variety of data types. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20210209211315.1261791-1-Julia.Lawall@inria.fr Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: core: rename 'dev' -> 'indio_dev' in iio_device_alloc()Alexandru Ardelean
The 'dev' variable name usually refers to 'struct device' types. However in iio_device_alloc() this was used for the 'struct iio_dev' type, which was sometimes causing minor confusions. This change renames the variable to 'indio_dev', which is the usual name used around IIO for 'struct iio_dev' type objects. It makes grepping a bit easier as well. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-22-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: buffer: introduce support for attaching more IIO buffersAlexandru Ardelean
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>
2021-03-11iio: core: wrap iio device & buffer into struct for character devicesAlexandru Ardelean
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>
2021-03-11iio: buffer: wrap all buffer attributes into iio_dev_attrAlexandru Ardelean
This change wraps all buffer attributes into iio_dev_attr objects, and assigns a reference to the IIO buffer they belong to. With the addition of multiple IIO buffers per one IIO device, we need a way to know which IIO buffer is being enabled/disabled/controlled. We know that all buffer attributes are device_attributes. So we can wrap them with a iio_dev_attr types. In the iio_dev_attr type, we can also hold a reference to an IIO buffer. So, we end up being able to allocate wrapped attributes for all buffer attributes (even the one from other drivers). The neat part with this mechanism, is that we don't need to add any extra cleanup, because these attributes are being added to a dynamic list that will get cleaned up via iio_free_chan_devattr_list(). With this change, the 'buffer->scan_el_dev_attr_list' list is being renamed to 'buffer->buffer_attr_list', effectively merging (or finalizing the merge) of the buffer/ & scan_elements/ attributes internally. Accessing these new buffer attributes can now be done via 'to_iio_dev_attr(attr)->buffer' inside the show/store handlers. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-15-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: add reference to iio buffer on iio_dev_attrAlexandru Ardelean
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>
2021-03-11iio: core: rework iio device group creationAlexandru Ardelean
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>
2021-03-11iio: core: register chardev only if neededAlexandru Ardelean
We only need a chardev if we need to support buffers and/or events. With this change, a chardev will be created only if an IIO buffer is attached OR an event_interface is configured. Otherwise, no chardev will be created, and the IIO device will get registered with the 'device_add()' call. Quite a lot of IIO devices don't really need a chardev, so this is a minor improvement to the IIO core, as the IIO device will take up (slightly) fewer resources. In order to not create a chardev, we mostly just need to not initialize the indio_dev->dev.devt field. If that is un-initialized, cdev_device_add() behaves like device_add(). This change has a small chance of breaking some userspace ABI, because it removes un-needed chardevs. While these chardevs (that are being removed) have always been unusable, it is likely that some scripts may check their existence (for whatever logic). And we also hope that before opening these chardevs, userspace would have already checked for some pre-conditions to make sure that opening these chardevs makes sense. For the most part, there is also the hope that it would be easier to change userspace code than revert this. But in the case that reverting this is required, it should be easy enough to do it. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-9-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: iio_format_value(): Fix IIO_VAL_FRACTIONAL_LOG2 values between -1.0 and 0.0Lars-Peter Clausen
When formatting a value using IIO_VAL_FRACTIONAL_LOG2 and the values is between -1 and 0 the sign is omitted. We need the same trick as for IIO_VAL_FRACTIONAL to make sure this gets formatted correctly. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201215191743.2725-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: iio_format_value(): Use signed temporary for IIO_VAL_FRACTIONAL_LOG2Lars-Peter Clausen
IIO_VAL_FRACTIONAL_LOG2 works with signed values, yet the temporary we use is unsigned. This works at the moment because the variable is implicitly cast to signed everywhere where it is used. But it will certainly be cleaner to use a signed variable in the first place. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201215191743.2725-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: core: Allow drivers to specify a label without it coming from ofHans de Goede
Only set indio_dev->label from of/dt if there actually is a label specified in of. This allows drivers to set a label without this being overwritten with NULL when there is no label specified in of. This is esp. useful on devices where of is not used at all, such as your typical x86/ACPI device. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210207160901.110643-2-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: Handle enumerated properties with gapsLars-Peter Clausen
Some enums might have gaps or reserved values in the middle of their value range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a meaning, but 2 is a reserved value and can not be used. Add support for such enums to the IIO enum helper functions. A reserved values is marked by setting its entry in the items array to NULL rather than the normal descriptive string value. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210107112049.10815-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: core: Copy iio_info.attrs->is_visible into ↵Hans de Goede
iio_dev_opaque.chan_attr_group.is_visible The iio-core extends the attr_group provided by the driver with its own attributes. To be able to do this it: 1. Has its own (non const) io_dev_opaque.chan_attr_group attr_group struct 2. It allocates a new attrs array with room for both the drivers and its own attributes 3. It copies over the driver provided attributes into the newly allocated attrs array. But the drivers attr_group may contain more then just the attrs array, it may also contain an is_visible callback and at least the adi-axi-adc.c is currently defining such a callback. Change the attr_group copying code to also copy over the is_visible callback, so that drivers can define one and have it workins as is normal for attr_group-s all over the kernel. Note that the is_visible callback takes an index into the array as argument, so that indices of the driver's attributes must not change, this is not a problem as the driver's own attributes are added first to the newly allocated attrs array and the attributes handled by the core are appended after the driver's attributes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20201125084606.11404-2-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: core: Simplify iio_format_list()Lars-Peter Clausen
iio_format_list() has two branches in a switch statement that are almost identical. They only differ in the stride that is used to iterate through the item list. Consolidate this into a common code path to simplify the code. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201114120000.6533-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: core: Consolidate iio_format_avail_{list,range}()Lars-Peter Clausen
The iio_format_avail_list() and iio_format_avail_range() functions are almost identical. The only differences are that iio_format_avail_range() expects a fixed amount of items and adds brackets "[ ]" around the output. Refactor them into a common helper function. This improves the maintainability of the code as it makes it easier to modify the implementation of these functions. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201114120000.6533-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>