summaryrefslogtreecommitdiffstats
path: root/drivers/iio
AgeCommit message (Collapse)Author
2020-11-21iio: triggered-buffer: add {devm_}iio_triggered_buffer_setup_ext variantsAlexandru Ardelean
This change adds a parameter to the {devm_}iio_triggered_buffer_setup() functions to assign the extra sysfs buffer attributes that are typically assigned via iio_buffer_set_attrs(). The functions also get renamed to iio_triggered_buffer_setup_ext() & devm_iio_triggered_buffer_setup_ext(). For backwards compatibility the old {devm_}iio_triggered_buffer_setup() functions are now macros wrap the new (renamed) functions with NULL for the buffer attrs. The aim is to remove iio_buffer_set_attrs(), so in the iio_triggered_buffer_setup_ext() function the attributes are assigned directly to 'buffer->attrs'. When adding multiple IIO buffers per IIO device, it can be pretty cumbersome to first allocate a set of buffers, then to dig them out of IIO to assign extra attributes (with iio_buffer_set_attrs()). Naturally, the best way would be to provide them at allocation time, which is what this change does. At this moment, buffers allocated with {devm_}iio_triggered_buffer_setup() are the only ones in mainline IIO to call iio_buffer_set_attrs(). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-4-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: adc: at91-sama5d2_adc: merge buffer & trigger init into a functionAlexandru Ardelean
This change is mostly cosmetic, but it's also a pre-cursor to the the change for 'iio_buffer_set_attrs()', where the helper gets updated to better support multiple IIO buffers for 1 IIO device. The only functional change is that the error message for the trigger alloc failure is bound to the parent device vs the IIO device object. Also, the new at91_adc_buffer_and_trigger_init() function was moved after the definition of the 'at91_adc_fifo_attributes'. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-3-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: buffer: dmaengine: unwrap the use of iio_buffer_set_attrs()Alexandru Ardelean
The iio_buffer_set_attrs() helper will be removed in this series. So, just assign the attributes of the DMAEngine buffer logic directly. This is IIO buffer core context, so there is direct access to the buffer->attrs object. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-2-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-14iio: adc: ad7887: convert probe to device-managed functionsAlexandru Ardelean
This is conversion of the driver to use device-managed functions. The IIO registration and triggered buffer setup both have device-managed versions. The regulator disable needs to be handled via an action_or_reset handler. With these changes, the remove hook is removed, and the error path is cleaned up in probe. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201113091648.148589-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-14iio: adc: stm32-adc: adapt clock duty cycle for proper operationFabrice Gasnier
For proper operation, STM32 ADC should be used with a clock duty cycle of 50%, in the range of 49% to 51%. Depending on the clock tree, divider can be used in case clock duty cycle is out of this range. In case clk_get_scaled_duty_cycle() returns an error, kindly apply a divider by default (don't make the probe fail). Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Link: https://lore.kernel.org/r/1604681846-31234-1-git-send-email-fabrice.gasnier@st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-14iio: core: centralize ioctl() calls to the main chardevAlexandru Ardelean
The aim of this is to improve a bit the organization of ioctl() calls in IIO core. Currently the chardev is split across IIO core sub-modules/files. The main chardev has to be able to handle ioctl() calls, and if we need to add buffer ioctl() calls, this would complicate things. The 'industrialio-core.c' file will provide a 'iio_device_ioctl()' which will iterate over a list of ioctls registered with the IIO device. These can be event ioctl() or buffer ioctl() calls, or something else. Each ioctl() handler will have to return a IIO_IOCTL_UNHANDLED code (which is positive 1), if the ioctl() did not handle the call in any. This eliminates any potential ambiguities about negative error codes, which should fail the call altogether. If any ioctl() returns 0, it was considered that it was serviced successfully and the loop will exit. This change also moves the handling of the IIO_GET_EVENT_FD_IOCTL command inside 'industrialio-event.c', where this is better suited. This patch is a combination of 2 other patches from an older series: Patch 1: iio: core: add simple centralized mechanism for ioctl() handlers Link: https://lore.kernel.org/linux-iio/20200427131100.50845-6-alexandru.ardelean@analog.com/ Patch 2: iio: core: use new common ioctl() mechanism Link: https://lore.kernel.org/linux-iio/20200427131100.50845-7-alexandru.ardelean@analog.com/ Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200924084155.99406-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-08iio: adc: mt6360: Add ADC driver for MT6360Gene Chen
Add MT6360 ADC driver including Charger Current, Voltage, and Temperature. Signed-off-by: Gene Chen <gene_chen@richtek.com> Link: https://lore.kernel.org/r/1603181267-15610-4-git-send-email-gene.chen.richtek@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-08iio: adc: stm32-adc: dma transfers cleanupOlivier Moysan
- Remove processing related to DMA in irq handler as this data transfer is managed directly in DMA callback. - Update comment in stm32_adc_set_watermark() function. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@st.com> Link: https://lore.kernel.org/r/20201105142941.27301-1-olivier.moysan@st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-08iio: adc: ad7768-1: Add channel labels.Cristian Pop
For better identification of the channels. Signed-off-by: Cristian Pop <cristian.pop@analog.com> Link: https://lore.kernel.org/r/20200928090959.88842-3-cristian.pop@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-08iio: core: Add optional symbolic label to a device channelCristian Pop
If a label is defined in the device tree for this channel add that to the channel specific attributes. This is useful for userspace to be able to identify an individual channel. Signed-off-by: Cristian Pop <cristian.pop@analog.com> Link: https://lore.kernel.org/r/20200928090959.88842-1-cristian.pop@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-01iio: remove unneeded breakTom Rix
A break is not needed if it is preceded by a return Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20201019172824.32166-1-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-01iio:light:tsl2563 use generic fw accessorsVaishnav M A
Replace of_property_read_u32() with device_property_read_u32(), when reading the amstaos,cover-comp-gain.This opens up the possibility of passing the properties during platform instantiation of the device by a suitable populated struct property_entry. Additionally, a minor change in logic is added to remove the of_node present check. Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org> Link: https://lore.kernel.org/r/20201018203552.GA816421@ubuntu Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-01iio: light: vcnl4035 add i2c_device_idVaishnav M A
Add i2c_device_id table for the vcnl4035 driver, enabling device instantiation using i2c_new_client_device() or from userspace in cases where device-tree based description is not possible now, like device(s) on a gbphy i2c adapter created by greybus. Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org> Link: https://lore.kernel.org/r/20201018195357.GA814864@ubuntu Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-01iio: proximity: vl53l0x-i2c add i2c_device_idVaishnav M A
Add i2c_device_id table for the vl53l0x-i2c driver, helps in device instantiation using i2c_new_client_device() or from userspace in cases where device-tree based description is not possible now, like device(s) on a gbphy i2c adapter created by greybus. Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org> Link: https://lore.kernel.org/r/20201018195102.GA814713@ubuntu Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-01iio: magnetometer: bmc150: remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201031134319.2134314-1-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-01iio: pressure: bmp280: remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201031134506.2134698-1-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-31iio: adc: at91-sama5d2_adc: remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201027200853.1596699-1-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-31iio/adc: ingenic: remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201027201128.1597230-1-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-31iio: light: apds9960: remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20201027201436.1597726-1-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: accel: mma8452: Constify static struct attribute_groupRikard Falkeborn
The only usage of mma8452_event_attribute_group is to assign its address to the event_attrs field in the iio_info struct, which is a const pointer. Make it const to allow the compiler to put it in read-only memory. This was the only non-const static struct in drivers/iio. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200930232939.31131-1-rikard.falkeborn@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: dac: ad7303: remove platform data headerAlexandru Ardelean
The information in the ad7303 platform_data header is unused, so it's dead code. This change removes it and it's inclusion from the driver. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201001141004.53846-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: ad7298: rework external ref setup & remove platform dataAlexandru Ardelean
This change removes the old platform data for ad7298. It is only used to provide whether to use an external regulator as a reference. So, the logic is inverted a bit. The driver now tries to obtain a regulator. If one is provided, then the external ref is used. The rest of the logic should work as before. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201001141048.69050-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: core: Fix IIO_VAL_FRACTIONAL calculation for negative valuesAnand Ashok Dumbre
Fixes IIO_VAL_FRACTIONAL for case when the result is negative and exponent is 0. example: if the result is -0.75, tmp0 will be 0 and tmp1 = 75 This causes the output to lose sign because of %d in snprintf which works for tmp0 <= -1. Reported-by: kernel test robot <lkp@intel.com> #error: uninitialized symbol tmp Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Anand Ashok Dumbre <anand.ashok.dumbre@xilinx.com> Link: https://lore.kernel.org/r/1601910316-24111-1-git-send-email-anand.ashok.dumbre@xilinx.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: exynos: do not rely on 'users' counter in ISRdmitry.torokhov@gmail.com
The order in which 'users' counter is decremented vs calling drivers' close() method is implementation specific, and we should not rely on it. Let's introduce driver private flag and use it to signal ISR to exit when device is being closed. This has a side-effect of fixing issue of accessing inut->users outside of input->mutex protection. Reported-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201006215509.GA2556081@dtor-ws Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: sx9310: Set various settings from DTStephen Boyd
These properties need to be set during driver probe. Parse any DT properties and replace the default register settings with the ones parsed from DT. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: <devicetree@vger.kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-7-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: sx9310: Support setting debounce valuesStephen Boyd
The rising and falling directions can be debounced in the hardware as "close" and "far" debounce settings. Add support for these as rising and falling debounce settings. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-5-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: sx9310: Support setting hysteresis valuesStephen Boyd
Add support for setting the hysteresis as a shifted value of a channel's proximity threshold. Each channel can have a different threshold, but the hysteresis applies to all channels as a right shift factor. Therefore, duplicate the hysteresis value across all channels and make it depend on the channel's proximity threshold. This is sort of odd but seems to work in practice as most of the time only one channel is used. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-4-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: sx9310: Support setting proximity thresholdsStephen Boyd
Add support to set the proximity thresholds for each channel. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-3-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: sx9310: Support hardware gain factorStephen Boyd
Add support to set the hardware gain of the channels as a multiplier of 2x, 4x, or 8x. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-2-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: imu: st_lsm6dsx: add support to LSM6DSTLorenzo Bianconi
Add support to STM LSM6DST (acc + gyro) Mems sensor https://www.st.com/resource/en/datasheet/lsm6dst.pdf Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/835127b76ef5ad05aa2aac58298aee5f3073fb71.1601985763.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: ad7887: invert/rework external ref logicAlexandru Ardelean
This change inverts/reworks the logic to use an external reference via a provided regulator. Now the driver tries to obtain a regulator. If one is found, then it is used. The rest of the driver logic already checks if there is a non-NULL reference to a regulator, so it should be fine. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201002082723.184810-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: at91_adc: remove platform data and move defs in driver fileAlexandru Ardelean
The AT91 ADC driver no longer uses the 'at91_add_device_adc' platform data type. This is no longer used (at least in mainline boards). This change removes the platform-data initialization from the driver, since it is mostly dead code now. Some definitions [from the platform data at91_adc.h include] have been moved in the driver, since they are needed in the driver. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-5-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: at91_adc: add Kconfig dep on the OF symbol and remove of_match_ptr()Alexandru Ardelean
This tries to solve a warning reported by the lkp bot: >> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable >> 'at91_adc_dt_ids' [-Wunused-const-variable] static const struct of_device_id at91_adc_dt_ids[] = { ^ 1 warning generated. This warning has appeared after the AT91_ADC driver compilation has been enabled via the COMPILE_TEST symbol dependency. The warning is caused by the 'of_match_ptr()' helper which returns NULL if OF is undefined. This driver should build only for device-tree context, so a dependency on the OF Kconfig symbol has been added. Also, the usage of of_match_ptr() helper has been removed since it shouldn't ever return NULL (because the driver should not be built for the non-OF context). Fixes: 4027860dcc4c ("iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-4-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: at91_adc: const-ify some driver dataAlexandru Ardelean
The main intent is to get rid of the cast for the void-pointer returned by of_device_get_match_data(). This requires const-ifying the 'caps' and 'registers' references on the at91_adc_state struct. The caps can be obtained also from the old platform_data (in the at91_adc_probe_pdata() function), but that cast is not touched in this patch, since the old platform_data should be removed/cleaned-away. Also, that cast deals with converting a kernel_ulong_t type to a pointer. So, updating that cast doesn't yield any benefit. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-3-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: adc: at91_adc: use of_device_get_match_data() helperAlexandru Ardelean
This is a small tidy-up. The of_device_get_match_data() helper retrieves the driver data from the OF table, without needed to explicitly know the table variable (since it can retrieve it from the driver object). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-2-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: dac: ad5686: add of_match_tableMichael Auchter
Add of_match_table to this driver, so devices can be probed based on device tree contents. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Link: https://lore.kernel.org/r/20200924195215.49443-2-michael.auchter@ni.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-10iio: dac: ad5686: add support for AD5338RMichael Auchter
The AD5338R is a 10-bit DAC with 2 outputs and an internal 2.5V reference (enabled by default). The register configuration is nearly identical to the AD5696R DAC that's already supported by this driver, with the channel selection bits being the only thing different. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Link: https://lore.kernel.org/r/20200924195215.49443-1-michael.auchter@ni.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-10-05Merge 5.9-rc8 into staging-nextGreg Kroah-Hartman
We need the IIO fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-29iio: adc: gyroadc: fix leak of device node iteratorTobias Jordan
Add missing of_node_put calls when exiting the for_each_child_of_node loop in rcar_gyroadc_parse_subdevs early. Also add goto-exception handling for the error paths in that loop. Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver") Signed-off-by: Tobias Jordan <kernel@cdqe.de> Link: https://lore.kernel.org/r/20200926161946.GA10240@agrajag.zerfleddert.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: adc: stm32-adc: fix runtime autosuspend delay when slow pollingFabrice Gasnier
When the ADC is runtime suspended and starting a conversion, the stm32-adc driver calls pm_runtime_get_sync() that gets cascaded to the parent (e.g. runtime resume of stm32-adc-core driver). This also kicks the autosuspend delay (e.g. 2s) of the parent. Once the ADC is active, calling pm_runtime_get_sync() again (upon a new capture) won't kick the autosuspend delay for the parent (stm32-adc-core driver) as already active. Currently, this makes the stm32-adc-core driver go in suspend state every 2s when doing slow polling. As an example, doing a capture, e.g. cat in_voltageY_raw at a 0.2s rate, the auto suspend delay for the parent isn't refreshed. Once it expires, the parent immediately falls into runtime suspended state, in between two captures, as soon as the child driver falls into runtime suspend state: - e.g. after 2s, + child calls pm_runtime_put_autosuspend() + 100ms autosuspend delay of the child. - stm32-adc-core switches off regulators, clocks and so on. - They get switched on back again 100ms later in this example (at 2.2s). So, use runtime_idle() callback in stm32-adc-core driver to call pm_runtime_mark_last_busy() for the parent driver (stm32-adc-core), to avoid this. Fixes: 9bdbb1139ca1 ("iio: adc: stm32-adc: add power management support") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/1593615328-5180-1-git-send-email-fabrice.gasnier@st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: adc: at91-sama5d2_adc: fix DMA conversion crashEugen Hristev
After the move of the postenable code to preenable, the DMA start was done before the DMA init, which is not correct. The DMA is initialized in set_watermark. Because of this, we need to call the DMA start functions in set_watermark, after the DMA init, instead of preenable hook, when the DMA is not properly setup yet. Fixes: f3c034f61775 ("iio: at91-sama5d2_adc: adjust iio_triggered_buffer_{predisable,postenable} positions") Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Link: https://lore.kernel.org/r/20200923121748.49384-1-eugen.hristev@microchip.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: ad7292: Fix of_node refcountingNuno Sá
When returning or breaking early from a `for_each_available_child_of_node()` loop, we need to explicitly call `of_node_put()` on the child node to possibly release the node. Fixes: 506d2e317a0a0 ("iio: adc: Add driver support for AD7292") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200925091045.302-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: ltc2983: Fix of_node refcountingNuno Sá
When returning or breaking early from a `for_each_available_child_of_node()` loop, we need to explicitly call `of_node_put()` on the child node to possibly release the node. Fixes: f110f3188e563 ("iio: temperature: Add support for LTC2983") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200925091045.302-1-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: buffer: Kconfig: add title for IIO_TRIGGERED_BUFFER symbolAlexandru Ardelean
For some embedded systems, a workflow involving external kernel modules that implement IIO devices is more practical than working with in-tree sources. Kconfig symbols without any titles do not show up in menuconfig, and as such are more difficult to configure granularly, as they need to be selected by potentially unused/un-needed drivers. This change adds a title to the IIO_TRIGGERED_BUFFER Kconfig symbol. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200924111758.196367-4-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: Kconfig: Provide title for IIO_TRIGGERED_EVENT symbolAlexandru Ardelean
For some embedded systems, a workflow involving external kernel modules that implement IIO devices is more practical than working with in-tree sources. Kconfig symbols without any titles do not show up in menuconfig, and as such are more difficult to configure granularly, as they need to be selected by potentially unused/un-needed drivers. Albeit, the IIO_TRIGGERED_EVENT is used by a single mainline driver, this could allow for some out-of-tree drivers to use this kmod. This change adds a title to the IIO_TRIGGERED_EVENT Kconfig symbol. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200924111758.196367-3-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: dma-buffer: Kconfig: Provide titles for IIO DMA Kconfig symbolsAlexandru Ardelean
For some embedded systems, a workflow involving external kernel modules that implement IIO devices is more practical than working with in-tree sources. Kconfig symbols without any titles do not show up in menuconfig, and as such are more difficult to configure granularly, as they need to be selected by potentially unused/un-needed drivers. This change adds titles to the IIO DMA Kconfig symbols to address this. This change also updates DMAengine -> DMAEngine, which is the correct/nitpick-y name of the framework. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200924111758.196367-2-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: cros_ec: unify hw fifo attributes into the core fileAlexandru Ardelean
The intent here is to minimize the use of iio_buffer_set_attrs(). Since we are planning to add support for multiple IIO buffers per IIO device, the issue has to do with: 1. Accessing 'indio_dev->buffer' directly (as is done with 'iio_buffer_set_attrs(indio_dev->buffer, <attrs>)'). 2. The way that the buffer attributes would get handled or expanded when there are more buffers per IIO device. Current a sysfs kobj_type expands into a 'device' object that expands into an 'iio_dev' object. We will need to change this, so that the sysfs attributes for IIO buffers expand into IIO buffers at some point. Right now, the current IIO framework works fine for the '1 IIO device == 1 IIO buffer' case (that is now). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20200923130339.997902-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: adc: ad9467: add support for AD9265 high-speed ADCMichael Hennerich
The AD9265 is a 16-bit, 125 MSPS analog-to-digital converter (ADC). The AD9265 is designed to support communications applications where high performance combined with low cost, small size, and versatility is desired. The ADC core features a multistage, differential pipelined architecture with integrated output error correction logic to provide 16-bit accuracy at 125 MSPS data rates and guarantees no missing codes over the full operating temperature range. The ADC features a wide bandwidth differential sample-and-hold analog input amplifier supporting a variety of user-selectable input ranges. It is suitable for multiplexed systems that switch full-scale voltage levels in successive channels and for sampling single-channel inputs at frequencies well beyond the Nyquist rate. Combined with power and cost savings over previously available ADCs, the AD9265 is suitable for applications in communications, instrumentation and medical imaging. Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD9434.pdf The driver supports the same register set as the AD9467, so the support for this chip is added to the 'ad9467' driver. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200924080518.96410-4-alexandru.ardelean@analog.com
2020-09-29iio: adc: ad9467: add support for AD9434 high-speed ADCMichael Hennerich
The AD9434 is a 12-bit monolithic sampling analog-to-digital converter (ADC) optimized for high performance, low power, and ease of use. The part operates at up to a 500 MSPS conversion rate and is optimized for outstanding dynamic performance in wideband carrier and broadband systems. All necessary functions, including a sample-and-hold and voltage reference, are included on the chip to provide a complete signal conversion solution. The VREF pin can be used to monitor the internal reference or provide an external voltage reference (external reference mode must be enabled through the SPI port). The ADC requires a 1.8 V analog voltage supply and a differential clock for full performance operation. The digital outputs are LVDS (ANSI-644) compatible and support twos complement, offset binary format, or Gray code. A data clock output is available for proper output data timing. Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD9434.pdf The driver supports the same register set as the AD9467, so the support for this chip is added to the 'ad9467' driver. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200924080518.96410-3-alexandru.ardelean@analog.com
2020-09-29iio: adc: ad9467: wrap a axi-adc chip-info into a ad9467_chip_info typeAlexandru Ardelean
There are 2 chip constants that can be added to the chip-info part. The default output-mode and the VREF mask. When adding new chips to this driver, these can be easily omitted, because these also need to be updated in 2 switch statements. However, if adding them in the chip-info constants, they are updated in a single place and propagated in both switch statements. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200924080518.96410-2-alexandru.ardelean@analog.com