- 19 Oct, 2021 40 commits
-
-
Cai Huoqing authored
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-6-caihuoqing@baidu.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Cai Huoqing authored
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by:
-
Cai Huoqing authored
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by:
-
Cai Huoqing authored
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20210928013902.1341-3-caihuoqing@baidu.comSigned-off-by:
-
Cai Huoqing authored
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by:
-
Cai Huoqing authored
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by:
-
Florian Boor authored
New binding documentation for AD799x series of I²C ADC ICs. Signed-off-by:
Florian Boor <florian.boor@kernelconcepts.de> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210930104249.2924336-2-florian.boor@kernelconcepts.deSigned-off-by:
-
Florian Boor authored
iio: adc: ad799x: Implement selecting external reference voltage input on AD7991, AD7995 and AD7999. Make use of the AD7991_REF_SEL bit and support using the external reference voltage if 'vref-supply' is present. Use VCC voltage supply as reference if no extra reference is supplied. Signed-off-by:
-
Dan Carpenter authored
Return -ETIMEDOUT on timeout instead of success. Fixes: 1f7b4048 ("iio: adc: max1027: Use the EOC IRQ when populated for single reads") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Jonathan Cameron authored
iio_push_to_buffers_with_timestamp() requires that the buffer is 8 byte alignment to ensure an inserted timestamp is naturally aligned. This requirement was not met here when burst mode is in use beause of a leading u16. Use the new iio_push_to_buffers_with_ts_unaligned() function that has more relaxed requirements. It is somewhat complex to access that actual data length, but a safe bound can be found by using scan_bytes - sizeof(timestamp) so that is used in this path. More efficient approaches exist, but this ensure correctness at the cost of using a bounce buffer. Fixes: 5075e072 ("iio: imu: adis: generalize burst mode support") Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613151039.569883-5-jic23@kernel.org
-
Jonathan Cameron authored
Fix a set of closely related issues. 1. When using fifo_values() there was not enough space for the timestamp to be inserted by iio_push_to_buffers_with_timestamp() 2. fifo_values() did not meet the alignment requirement of iio_push_to_buffers_with_timestamp() 3. hw_values did not meet the alignment requirement either. 1 and 2 fixed by using new iio_push_to_buffers_with_ts_unaligned() which has no alignment or space padding requirements. 3 fixed by introducing a structure that makes the space and alignment requirements explicit. Fixes: 3904b28e ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210613151039.569883-4-jic23@kernel.org
-
Jonathan Cameron authored
Use the newly introduce iio_push_to_buffers_with_ts_unaligned() function to ensure a bounce buffer is used to provide the required alignment and space padding needed by the IIO core which requires the timestamp is naturally aligned. There will be a performance cost to this change but it will ensure the driver works on platforms that do not support unaligned 8 byte assignments, and with consumer drivers that may assume natural alignment of the timestamp. Issue found as part of an audit of all calls to iio_push_to_buffers_with_timestamp() Fixes: 7e87d11c ("iio: adc: Add support for TI ADC108S102 and ADC128S102") Signed-off-by:
-
Jonathan Cameron authored
Whilst it is almost always possible to arrange for scan data to be read directly into a buffer that is suitable for passing to iio_push_to_buffers_with_timestamp(), there are a few places where leading data needs to be skipped over. For these cases introduce a function that will allocate an appropriate sized and aligned bounce buffer (if not already allocated) and copy the unaligned data into that before calling iio_push_to_buffers_with_timestamp() on the bounce buffer. We tie the lifespace of this buffer to that of the iio_dev.dev which should ensure no memory leaks occur. Signed-off-by:
-
Randy Dunlap authored
Fix kconfig symbol dependency warning: WARNING: unmet direct dependencies detected for REGMAP_I2C Depends on [n]: I2C [=n] Selected by [y]: - SENSEAIR_SUNRISE_CO2 [=y] && IIO [=y] Fixes: c397894e ("iio: chemical: Add Senseair Sunrise 006-0-007 drive") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Jacopo Mondi <jacopo@jmondi.org> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: linux-iio@vger.kernel.org Link: https://lore.kernel.org/r/20211002232803.5108-1-rdunlap@infradead.orgSigned-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20211001120018.17570-1-colin.king@canonical.comSigned-off-by:
-
Alexandru Ardelean authored
This is a simple conversion for to device-managed with using devm_request_threaded_irq(), disabling the regulator via a devm_add_action_or_reset() hook and finally using devm_iio_device_register(). The i2c_set_clientdata() call is removed as it becomes redundant after this change. Signed-off-by:
Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210926194315.7742-1-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
Otherwise most build checks will omit this driver from a compile-test due to it's dependency only on the BERLIN_ARCH symbol. Signed-off-by:
-
Alexandru Ardelean authored
This driver requires only a devm_add_action_or_reset() hook for the power-down of the device, and then devm_iio_device_register() can be used directly. Signed-off-by:
-
Alexandru Ardelean authored
This driver already hooks a similar unwind callback via devm_add_action_or_reset(). They pretty much do the same thing, so this change converts it to the devm_iio_map_array_register(). Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20210926162859.3567685-1-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
For this conversion, the 2 regulators (being enabled) require each a devm_add_action_or_reset() hook registration. For the other functions, there are device-managed variants. Signed-off-by:
-
Alexandru Ardelean authored
This is a trivial conversion to device-managed functions. The mutex_destroy() calls are redundant, as the data will be free'd anyway. And the IRQ and IIO register functions both have device-managed equivalents. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210926154932.3287590-1-aardelean@deviqon.comSigned-off-by:
-
Nuno Sá authored
The library can now handle enabling/disabling IRQs for devices that cannot unmask the data ready pin. Hence there's no need to provide an 'enable_irq' callback anymore. The library will also automatically request the IRQ with 'IRQF_NO_AUTOEN' so that we can also remove that from the driver. Signed-off-by:
-
Nuno Sá authored
The library can now handle enabling/disabling IRQs for devices that cannot unmask the data ready pin. Hence there's no need to provide an 'enable_irq' callback anymore. The library will also automatically request the IRQ with 'IRQF_NO_AUTOEN' so that we can also remove that from the driver. Signed-off-by:
-
Nuno Sá authored
Some devices can't mask/unmask the data ready pin and in those cases each driver was just calling '{dis}enable_irq()' to control the trigger state. This change, moves that handling into the library by introducing a new boolean in the data structure that tells the library that the device cannot unmask the pin. On top of controlling the trigger state, we can also use this flag to automatically request the IRQ with 'IRQF_NO_AUTOEN' in case it is set. So far, all users of the library want to start operation with IRQs/DRDY pin disabled so it should be fairly safe to do this inside the library. Signed-off-by: -
Nuno Sá authored
With commit ecb010d4 ("iio: imu: adis: Refactor adis_initial_startup") we are doing a HW or SW reset to the device which means that we'll get the default state of the data ready pin (which is enabled). Hence there's no point in disabling the IRQ in the init function. Moreover, this function is intended to initialize internal data structures and not really do anything on the device. As a result of this, some devices were left with the data ready pin enabled after probe which was not the desired behavior. Thus, we move the call to 'adis_enable_irq()' to the initial startup function where it makes more sense for it to be. Note that for devices that cannot mask/unmask the pin, it makes no sense to call the function at this point since the IRQ should not have been yet requested. This will be improved in a follow up change. Fixes: ecb010d4 ("iio: imu: adis: Refactor adis_initial_startup") Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed functions only, which means that the remove hook can be removed. The remove hook has only 2 calls to iio_device_unregister() and iio_map_array_unregister(). Both these can now be done via devm register functions, now that there's also a devm_iio_map_array_register() function. The platform_set_drvdata() can also be removed now. This change also removes the error print for when the iio_device_register() call fails. This isn't required now. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed functions only, which means that the remove hook can be removed. The remove hook has only 2 calls to iio_device_unregister() and iio_map_array_unregister(). Both these can now be done via devm register functions, now that there's also a devm_iio_map_array_register() function. The platform_set_drvdata() can also be removed now. This change also removes the error print for when the iio_device_register() call fails. This isn't required now. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed functions only, which means that the remove hook can be removed. The remove hook has only 2 calls to iio_device_unregister() and iio_map_array_unregister(). Both these can now be done via devm register functions, now that there's also a devm_iio_map_array_register() function. The platform_set_drvdata() can also be removed now. This change also removes the error print for when the iio_device_register() call fails. This isn't required now. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210903072917.45769-4-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
The only call in the remove hook is the iio_map_array_unregister() call. Since we have a devm_iio_map_array_register() function now, we can use that and remove the remove hook entirely. The IIO device was registered with the devm_iio_device_register() prior to this change. Also, the platform_set_drvdata() can be removed now, since it was used only in the remove hook. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210903072917.45769-3-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
This change introduces a device-managed variant to the iio_map_array_register() function. It's a simple implementation of calling iio_map_array_register() and registering a callback to iio_map_array_unregister() with the devm_add_action_or_reset(). The function uses an explicit 'dev' parameter to bind the unwinding to. It could have been implemented to implicitly use the parent of the IIO device, however it shouldn't be too expensive to callers to just specify to which device object to bind this unwind call. It would make the API a bit more flexible. Signed-off-by:
-
Alexandru Ardelean authored
The driver tries to initialize all possible regulators from the DT, then match the external regulators with each channel and then release all unused regulators. We can change the logic a bit to initialize regulators only when at least one channel needs them. This change creates a mx25_gcq_ext_regulator_setup() function that is called only for the external regulators. If there's already a reference to an external regulator, the function will just exit early with no error. This way, the driver doesn't need to keep any track of these regulators during init. Signed-off-by:
-
Lorenzo Bianconi authored
Move max_fifo_size in st_lsm6dsx_fifo_ops in order to have all FIFO configuration parameters in st_lsm6dsx_fifo_ops structure. This patch does not introduce any logic change, just small code rearrangement. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/3262ad9d9d1497e19ea1bab208c495c2b9a98994.1632664866.git.lorenzo@kernel.orgSigned-off-by:
-
Miquel Raynal authored
External triggers do not necessarily need the EOC interrupt to be populated to work properly. The end of conversion status may either come from an interrupt or from a sufficient enough extra delay. IRQs are not mandatory so move the triggered buffer setup out of the IRQ condition and add the logic to wait enough time for all the requested conversions to be in the device's FIFO. Signed-off-by:
-
Miquel Raynal authored
There is no reason to limit this driver to its internal trigger. The only difference being, when using an external trigger, the sample conversion must be manually started. Drop the ->validate_trigger() hook in order to allow other triggers to be bound. Signed-off-by:
-
Miquel Raynal authored
So far the End-Of-Conversion interrupt was only used in conjunction with the internal trigger to process the data. Let's extend the use of this interrupt handler to support regular single-shot conversions as well. Doing so requires writing our own hard IRQ handler. This handler has to check if buffers are enabled or not: *** Buffers disabled condition *** This means the user requested a single conversion and the sample is ready to be retrieved. -> This implies adding the relevant completion boilerplate. *** Buffers enabled condition *** Triggers are used. So far there is only support for the internal trigger but this trigger might soon be attached to another device as well so it is the core duty to decide which handler to call in order to process the data. The core will decide to either: * Call the internal trigger handler which will extract the data that is already present in the ADC FIFOs or * Call the trigger handler of another driver when using this trigger with another device, even though this call will be slightly delayed by the fact that the max1027 IRQ is a data-ready interrupt rather than a real trigger: -> The new handler will manually inform the core about the trigger having transitioned by directly calling iio_trigger_poll() (which iio_trigger_generic_data_rdy_poll() initially did). In order for the handler to be "source" agnostic, we also need to change the private pointer and provide the IIO device instead of the trigger object. Signed-off-by: -
Miquel Raynal authored
The threaded handler is not populated, this means there is nothing running in process context so let's switch to the regular devm_request_irq() call instead. Signed-off-by:
-
Miquel Raynal authored
For now this helper only waits for the maximum duration of a single conversion. In practice, a "temperature measurement" will take twice this time because it will also carry another analog conversion but as here we will only care about the temperature conversion which happens first, we can still only wait for a single sample and get the right data. This helper will soon be improved to properly handle the end of conversion interrupt as well as a higher number of samples. Signed-off-by:
-
Miquel Raynal authored
Create a max1027_read_scan() helper which will make clearer the future IRQ handler updates (no functional change). Signed-off-by:
-
Miquel Raynal authored
When hardware buffers are enabled (the cnvst pin being the trigger), one should not mess with the device state by requesting a single channel read. There is already a iio_buffer_enabled() check in *_read_single_value() to merely prevent this situation but the check is inconsistent since buffers can be enabled after the if clause anyway. Instead, use the core mutex by calling iio_device_claim/release_direct_mode(). Signed-off-by:
-
Miquel Raynal authored
These bits are meant to be reused for triggered buffers setup. Signed-off-by:
-
