The iio_simple_dummy_configure_buffer() function is essentially a
re-implementation of the iio_triggered_buffer_setup() function.
This change makes use of the iio_triggered_buffer_setup() function. The
reason is so that we don't have to modify the iio_device_attach_buffer()
function in this driver as well.
One minor drawback is that the pollfunc name may not be 100% identical
with the one in the original code, but since it's an example, it should be
a big problem.
This change does a minor re-arranging of the included iio headers, as a
minor tidy-up.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-19-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The __iio_buffer_free_sysfs_and_mask() function will be used in
iio_buffer_alloc_sysfs_and_mask() when multiple buffers will be attached to
the IIO device.
This will need to be used to cleanup resources on each buffer, when the
buffers cleanup unwind will occur on the error path.
The move is done in this patch to make the patch that adds multiple buffers
per IIO device a bit cleaner.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-18-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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>
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>
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>
With this change, we create a new directory for the IIO device called
buffer0, under which both the old buffer/ and scan_elements/ are stored.
This is done to simplify the addition of multiple IIO buffers per IIO
device. Otherwise we would need to add a bufferX/ and scan_elementsX/
directory for each IIO buffer.
With the current way of storing attribute groups, we can't have directories
stored under each other (i.e. scan_elements/ under buffer/), so the best
approach moving forward is to merge their attributes.
The old/legacy buffer/ & scan_elements/ groups are not stored on the opaque
IIO device object. This way the IIO buffer can have just a single
attribute_group object, saving a bit of memory when adding multiple IIO
buffers.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-13-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
If we want to merge the attributes of the buffer/ and scan_elements/
directories, we'll need to count all attributes first, then (depending on
the attribute group) either allocate 2 attribute groups, or a single one.
Historically an IIO buffer was described by 2 subdirectories under
/sys/bus/iio/iio:devicesX (i.e. buffer/ and scan_elements/); these subdirs
were actually 2 separate attribute groups on the iio_buffer object.
Moving forward, if we want to allow more than one buffer per IIO device,
keeping 2 subdirectories for each IIO buffer is a bit cumbersome
(especially for userpace ABI). So, we will merge the attributes of these 2
subdirs under a /sys/bus/iio/iio:devicesX/bufferY subdirectory. To do this,
we need to count all attributes first, and then distribute them based on
which buffer this is. For the first buffer, we'll need to also allocate the
legacy 2 attribute groups (for buffer/ and scan_elements/), and also a
/sys/bus/iio/iio:devicesX/buffer0 attribute group.
For buffer1 and above, just a single attribute group will be allocated (the
merged one).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-12-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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>
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>
Currently, only the 'i' 0x90 ioctl() actually exists and is defined in
'include/uapi/linux/iio/events.h'.
It's the IIO_GET_EVENT_FD_IOCTL, which is used to retrieve and FD for
reading events from an IIO device.
We will want to add more ioct() numbers, so with this change the 'i'
0x90-0x9F space is reserved for IIO ioctl() calls.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-8-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change does a conversion of the devm_iio_dmaengine_buffer_alloc() to
devm_iio_dmaengine_buffer_setup(). This will allocate an IIO DMA buffer and
attach it to the IIO device, similar to devm_iio_triggered_buffer_setup()
(though the underlying code is different, the final logic is the same).
Since the only user of the devm_iio_dmaengine_buffer_alloc() was the
adi-axi-adc driver, this change does the replacement in a single go in the
driver.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-7-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
At this point all drivers should use devm_iio_kfifo_buffer_setup() instead
of manually allocating via devm_iio_kfifo_allocate() and assigning ops and
modes.
With this change, the devm_iio_kfifo_allocate() will be made private to the
IIO core, since all drivers should call either
devm_iio_kfifo_buffer_setup() or devm_iio_triggered_buffer_setup() to
create a kfifo buffer.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-6-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change makes use of the devm_iio_kfifo_buffer_setup() helper, however
the unwind order is changed.
The life-time of the kfifo object is attached to the parent device object.
This is to make the driver a bit more consistent with the other IIO
drivers, even though (as it is now before this change) it shouldn't be a
problem.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-5-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
All drivers that already call devm_iio_kfifo_allocate() &
iio_device_attach_buffer() are simple to convert to
iio_device_attach_kfifo_buffer() in a single go.
This change does that; the unwind order is preserved.
What is important, is that the devm_iio_kfifo_buffer_setup() be called
after the indio_dev->modes is assigned, to make sure that
INDIO_BUFFER_SOFTWARE flag is set and not overridden by the assignment to
indio_dev->modes.
Also, the INDIO_BUFFER_SOFTWARE has been removed from the assignments of
'indio_dev->modes' because it is set by devm_iio_kfifo_buffer_setup().
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>x
Link: https://lore.kernel.org/r/20210215104043.91251-4-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change adds the devm_iio_kfifo_buffer_setup() helper/short-hand,
which groups the simple routine of allocating a kfifo buffers via
devm_iio_kfifo_allocate() and calling iio_device_attach_buffer().
The mode_flags parameter is required, as the IIO kfifo supports 2 modes:
INDIO_BUFFER_SOFTWARE & INDIO_BUFFER_TRIGGERED.
The setup_ops parameter is optional.
This function will be a bit more useful when needing to define multiple
buffers per IIO device.
The naming for this function has been inspired from
iio_triggered_buffer_setup() since that one does a kfifo alloc + a pollfunc
alloc. So, this should have a more familiar ring to what it is.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-3-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The IIO core provides a function to do formatting of fixedpoint numbers.
In the past there have been some issues with the implementation of the
function where for example negative numbers were not handled correctly.
Introduce a basic unit test based on kunit that tests the function and
ensures that the generated output matches the expected output.
This gives us some confidence that future modifications to the function
implementation will not break ABI compatibility.
To run the unit tests follow the kunit documentation and add
CONFIG_IIO=y
CONFIG_IIO_TEST_FORMAT=y
to the .kunitconfig and run
> ./tools/testing/kunit/kunit.py run
Configuring KUnit Kernel ...
Building KUnit Kernel ...
Starting KUnit Kernel ...
============================================================
======== [PASSED] iio-format ========
[PASSED] iio_test_iio_format_value_integer
[PASSED] iio_test_iio_format_value_fixedpoint
[PASSED] iio_test_iio_format_value_fractional
[PASSED] iio_test_iio_format_value_fractional_log2
[PASSED] iio_test_iio_format_value_multiple
============================================================
Testing complete. 21 tests run. 0 failed. 0 crashed.
Elapsed time: 8.242s total, 0.001s configuring, 3.865s building, 0.000s running
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201215191743.2725-3-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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>
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
use 2 KXCJ91008 accelerometers:
1 in their display using an ACPI HID of "KIOX010A"; and
1 in their base using an ACPI HID of "KIOX020A"
Since in this case we know the location of each accelerometer,
set the label for the accelerometers to the standardized
"accel-display" resp. "accel-base" labels. This way userspace
can use the labels to get the location.
This was tested on a Medion Akoya E2228T MD60250.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210207160901.110643-4-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
use 2 bmc150 accelerometers, defined by a single BOSC0200 ACPI
device node (1 in their base and 1 in their display).
Since in this case we know the location of each accelerometer,
set the label for the accelerometers to the standardized
"accel-display" resp. "accel-base" labels. This way userspace
can use the labels to get the location.
This was tested on a Lenovo ThinkPad Yoga 11e 4th gen (N3450 CPU).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210207160901.110643-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For non-DMA usage, we have an easy way to associate a timestamp with a
sample: iio_pollfunc_store_time stores a timestamp in the primary
trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
to push out the buffer along with the timestamp.
For this to work, the driver needs to register an IIO_TIMESTAMP channel.
Do this.
For DMA, it's not as easy, because we don't push the buffers out of
stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
a tasklet scheduled after a DMA completion.
Preferably, the DMA controller would copy us the timestamp into that buffer
as well. Until this is implemented, restrict timestamping support to
only PIO. For low-frequency sampling, PIO is probably good enough.
Cc: Holger Assmann <has@pengutronix.de>
Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20210125194824.30549-1-a.fatoum@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Currently, the STM32 LP Timer counter driver registers into both IIO and
counter subsystems, which is redundant.
Remove the IIO counter ABI and IIO registration from the STM32 LP Timer
counter driver since it's been superseded by the Counter subsystem
as discussed in [1].
Keep only the counter subsystem related part.
Move a part of the ABI documentation into a driver comment.
This also removes a duplicate ABI warning
$ scripts/get_abi.pl validate
...
/sys/bus/iio/devices/iio:deviceX/in_count0_preset is defined 2 times:
./Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:100
./Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:0
[1] https://lkml.org/lkml/2021/1/19/347
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/1611926542-2490-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Seems that there are config combinations in which this driver gets enabled
and hence selects the MFD, but with out HAS_IOMEM getting pulled in
via some other route. MFD is entirely contained in an
if HAS_IOMEM block, leading to the build issue in this bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=209889
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#24: FILE: hal/HalBtc8723b1Ant.h:24:
+typedef enum _BT_INFO_SRC_8723B_1ANT {
WARNING: do not add new typedefs
#31: FILE: hal/HalBtc8723b1Ant.h:31:
+typedef enum _BT_8723B_1ANT_BT_STATUS {
WARNING: do not add new typedefs
#41: FILE: hal/HalBtc8723b1Ant.h:41:
+typedef enum _BT_8723B_1ANT_WIFI_STATUS {
WARNING: do not add new typedefs
#51: FILE: hal/HalBtc8723b1Ant.h:51:
+typedef enum _BT_8723B_1ANT_COEX_ALGO {
WARNING: do not add new typedefs
#66: FILE: hal/HalBtc8723b1Ant.h:66:
+typedef struct _COEX_DM_8723B_1ANT {
WARNING: do not add new typedefs
#121: FILE: hal/HalBtc8723b1Ant.h:121:
+typedef struct _COEX_STA_8723B_1ANT {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305100146.30687-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#19: FILE: hal/HalBtc8723b2Ant.h:19:
+typedef enum _BT_INFO_SRC_8723B_2ANT {
WARNING: do not add new typedefs
#26: FILE: hal/HalBtc8723b2Ant.h:26:
+typedef enum _BT_8723B_2ANT_BT_STATUS {
WARNING: do not add new typedefs
#36: FILE: hal/HalBtc8723b2Ant.h:36:
+typedef enum _BT_8723B_2ANT_COEX_ALGO {
WARNING: do not add new typedefs
#51: FILE: hal/HalBtc8723b2Ant.h:51:
+typedef struct _COEX_DM_8723B_2ANT {
WARNING: do not add new typedefs
#104: FILE: hal/HalBtc8723b2Ant.h:104:
+typedef struct _COEX_STA_8723B_2ANT {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305101151.13137-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#11: FILE: hal/HalPhyRf.h:11:
+typedef enum _SPUR_CAL_METHOD {
WARNING: do not add new typedefs
#16: FILE: hal/HalPhyRf.h:16:
+typedef enum _PWRTRACK_CONTROL_METHOD {
WARNING: do not add new typedefs
#27: FILE: hal/HalPhyRf.h:27:
+typedef struct _TXPWRTRACK_CFG {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305144906.18850-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix some "incorrect type in assignment" warnings reported by sparse in fw.c
sparse warnings:
wimax/i2400m/fw.c:266:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:266:25: warning: incorrect type in assignment (different base types)
wimax/i2400m/fw.c:267:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:267:25: warning: incorrect type in assignment (different base types)
wimax/i2400m/fw.c:268:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:268:25: warning: incorrect type in assignment (different base types)
wimax/i2400m/fw.c:269:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:269:25: warning: incorrect type in assignment (different base types)
Signed-off-by: Darryl T. Agostinelli <dagostinelli@gmail.com>
Link: https://lore.kernel.org/r/20210308144839.2364329-1-dagostinelli@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
