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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 4027860dcc ("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>
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>
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>
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>
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>
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: 059c53b323 ("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>
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: 9bdbb1139c ("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>
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: f3c034f617 ("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>
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: 506d2e317a ("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>
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: f110f3188e ("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>
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>
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>
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>
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>
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
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
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
This is to encourage the use of devm_iio_dmaengine_buffer_alloc().
Currently the managed version of the DMAEngine buffer alloc is the only
function used from this part of the framework.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200923121810.944075-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make use of devm_platform_get_and_ioremap_resource() provided by
driver core platform instead of duplicated analogue, dev_err() is
removed because it has been done in devm_ioremap_resource().
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20200918083142.32816-1-bobo.shaobowang@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make use of devm_platform_get_and_ioremap_resource() provided by
driver core platform instead of duplicated analogue.
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20200918082837.32610-1-bobo.shaobowang@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use PLATFORM_DEVID_NONE define instead of "-1" value because:
- it brings some meaning,
- it might point attention why auto device ID was not used.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200921204939.20341-1-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There are no in-tree users of the platform data for this driver, so
remove it and convert the driver to use device tree instead.
Signed-off-by: Michael Auchter <michael.auchter@ni.com>
Link: https://lore.kernel.org/r/20200922144422.542669-1-michael.auchter@ni.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Though we know that the iio_device_unregister_eventset() call is followed
by the free-ing of the IIO device object, we should not make this
assumption in the iio_device_unregister_eventset() function. It should
allow for the clean unregistering of the event-set, allowing a re-register
should we decide to implement this at some point later.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200921103156.194748-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
With the recent 'iio_dev_opaque' variable name, these two functions are
looking a bit ugly.
This change uses an 'ev_int' variable for the
iio_device_{un}register_eventset functions to make the code a little easier
to read.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200921103156.194748-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
