- 11 Mar, 2021 40 commits
-
-
Ye Xiang authored
Before, when reading/writing the hysteresis of als, incli-3d, press, and rotation sensor, we will get invalid argument error. This patch add more sensitivity data fields for these sensors, so that these sensors can get sensitivity index and return correct hysteresis value. Signed-off-by:
Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210201054921.18214-3-xiang.ye@intel.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Ye Xiang authored
No functional change has been made with this patch. The main intent here is to reduce code repetition of getting sensitivity attribute. In the current implementation, sensor_hub_input_get_attribute_info() is called from multiple drivers to get attribute info for sensitivity field. Moving this to common place will avoid code repetition. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210201054921.18214-2-xiang.ye@intel.comSigned-off-by:
-
Luca Ceresoli authored
Show that this field is optional, just like the shift value. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Link: https://lore.kernel.org/r/20210215143511.25471-6-luca@lucaceresoli.netSigned-off-by:
-
Luca Ceresoli authored
This 2nd-level bullet list is not properly ReST-formatted and thus it gets rendered as a unique paragraph quite unreadable. Fix by adding spaces as needed. While there also swap "shift" and "repeat" so they are in the correct order. Signed-off-by:
-
Luca Ceresoli authored
Two out of three attributes are documented, document the third one too. Signed-off-by:
-
Luca Ceresoli authored
This directory is a, well, directory, not a file. Signed-off-by:
-
Luca Ceresoli authored
This line is part of the code snippet, so it has to be nested in order to be rendered correctly. Signed-off-by:
-
Julia Lawall authored
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.frSigned-off-by:
-
Alexandru Ardelean authored
This change makes use of the new IIO buffer API to read data from an IIO buffer. It doesn't read the /sys/bus/iio/devices/iio:deviceX/scan_elements dir anymore, it reads /sys/bus/iio/devices/iio:deviceX/bufferY, where all the scan_elements have been merged together with the old/classical buffer attributes. And it makes use of the new IIO_BUFFER_GET_FD_IOCTL ioctl to get an FD for the IIO buffer for which to read data from. It also does a quick sanity check to see that -EBUSY is returned if reading the chardev after the ioctl() has succeeded. This was tested with the following cases: 1. Tested buffer0 works with ioctl() 2. Tested that buffer0 can't be opened via /dev/iio:deviceX after ioctl() This check should be omitted under normal operation; it's being done here to check that the driver change is sane 3. Moved valid buffer0 to be buffer1, and tested that data comes from it Signed-off-by:Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-25-alexandru.ardelean@analog.comSigned-off-by:
-
Alexandru Ardelean authored
Mostly a tidy-up. But also helps to understand the limits of scope of these functions and globals. Signed-off-by:
-
Alexandru Ardelean authored
This is a bit of a tidy-up, but also helps with extending the iioutils_get_type() function a bit, as we don't need to use it outside of the iio_utils.c file. So, we'll need to update it only in one place. With this change, the 'unsigned' types are updated to 'unsigned int' in the iioutils_get_type() function definition. Signed-off-by:
-
Alexandru Ardelean authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
The reference to the IIO buffer object is stored on the attribute object. So we need to unwind it to obtain it. Signed-off-by:
-
Alexandru Ardelean authored
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 authored
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 authored
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 authored
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 authored
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 authored
Oddly enough the noop function is an int-return. This one seems to be void. This change converts it to int, because we want to change how groups are registered. With that change this function could error out with -ENOMEM. Signed-off-by:
-
Alexandru Ardelean authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
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.comSigned-off-by:
-
Alexandru Ardelean authored
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:
-
Lars-Peter Clausen authored
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.deSigned-off-by:
-
Lars-Peter Clausen authored
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 authored
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:
-
Bhaskar Chowdhury authored
s/postive/positive/ Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210210085704.1228068-1-unixbhaskar@gmail.comSigned-off-by:
-
Hans de Goede authored
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.comSigned-off-by:
-
Hans de Goede authored
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 authored
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:
-
Tomislav Denis authored
Add a device tree binding documentation for Texas Instruments ADS131E0x ADC family driver. Signed-off-by:
Tomislav Denis <tomislav.denis@avl.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210202084107.3260-3-tomislav.denis@avl.comSigned-off-by:
-
Tomislav Denis authored
The ADS131E0x are a family of multichannel, simultaneous sampling, 24-bit, delta-sigma, analog-to-digital converters (ADCs) with a built-in programmable gain amplifier (PGA), internal reference and an onboard oscillator. Datasheet: https://www.ti.com/lit/ds/symlink/ads131e08.pdfSigned-off-by:
-
