dt-bindings: iio: vishay,vcnl4000: add interrupts property

The dtschema should list all properties, including the common ones like
interrupts.  This fixes dtbs_check warnings like:

  arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dt.yaml:
    prox@60: 'interrupt-parent', 'interrupts' do not match any of the regexes: 'pinctrl-[0-9]+'

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200920203845.17758-1-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:imu:inv_mpu6050: Use regmap_noinc_read for fifo reads.

We should not be assuming that we are reading a sequence of
registers as here we are doing a read of a lot of data from
a single register address.

Not marked for stable as by coincidence it being wrong doesn't
make any difference.

Suggested-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20200722155103.979802-19-jic23@kernel.org

iio:imu:inv_mpu6050 Fix dma and ts alignment and data leak issues.

This case is a bit different to the rest of the series.  The driver
was doing a regmap_bulk_read into a buffer that wasn't dma safe
as it was on the stack with no guarantee of it being in a cacheline
on it's own.   Fixing that also dealt with the data leak and
alignment issues that Lars-Peter pointed out.

Also removed some unaligned handling as we are now aligned.

Fixes tag is for the dma safe buffer issue. Potentially we would
need to backport timestamp alignment futher but that is a totally
different patch.

Fixes: fd64df16f40e ("iio: imu: inv_mpu6050: Add SPI support for MPU6000")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722155103.979802-18-jic23@kernel.org

iio:adc:ti-adc12138 Fix alignment issue with timestamp

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.

We move to a suitable structure in the iio_priv() data with alignment
explicitly requested.  This data is allocated with kzalloc so no
data can leak apart from previous readings. Note that previously
no leak at all could occur, but previous readings should never
be a problem.

In this case the timestamp location depends on what other channels
are enabled. As such we can't use a structure without misleading
by suggesting only one possible timestamp location.

Fixes: 50a6edb1b6e0 ("iio: adc: add ADC12130/ADC12132/ADC12138 ADC driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722155103.979802-26-jic23@kernel.org

iio:adc:ti-adc0832 Fix alignment issue with timestamp

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.

We fix this issues by moving to a suitable structure in the iio_priv()
data with alignment explicitly requested.  This data is allocated
with kzalloc so no data can leak apart from previous readings.
Note that previously no data could leak 'including' previous readings
but I don't think it is an issue to potentially leak them like
this now does.

In this case the postioning of the timestamp is depends on what
other channels are enabled. As such we cannot use a structure to
make the alignment explicit as it would be missleading by suggesting
only one possible location for the timestamp.

Fixes: 815bbc87462a ("iio: ti-adc0832: add triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722155103.979802-25-jic23@kernel.org

iio:imu:st_lsm6dsx Fix alignment and data leak issues

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here.  We close both issues by
moving to an array of suitable structures in the iio_priv() data.

This data is allocated with kzalloc so no data can leak apart from
previous readings.

For the tagged path the data is aligned by using __aligned(8) for
the buffer on the stack.

There has been a lot of churn in this driver, so likely backports
may be needed for stable.

Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722155103.979802-17-jic23@kernel.org

iio:light:si1145: Fix timestamp alignment and prevent data leak.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses a 24 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here.  We close both issues by
moving to a suitable array in the iio_priv() data with alignment
explicitly requested.  This data is allocated with kzalloc so no
data can leak appart from previous readings.

Depending on the enabled channels, the  location of the timestamp
can be at various aligned offsets through the buffer.  As such we
any use of a structure to enforce this alignment would incorrectly
suggest a single location for the timestamp.  Comments adjusted to
express this clearly in the code.

Fixes: ac45e57f1590 ("iio: light: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient light, uv index and proximity sensors")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722155103.979802-9-jic23@kernel.org

iio:gyro:itg3200: Fix timestamp alignment and prevent data leak.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses a 16 byte array of smaller elements on the stack.
This is fixed by using an explicit c structure. As there are no
holes in the structure, there is no possiblity of data leakage
in this case.

The explicit alignment of ts is not strictly necessary but potentially
makes the code slightly less fragile.  It also removes the possibility
of this being cut and paste into another driver where the alignment
isn't already true.

Fixes: 36e0371e7764 ("iio:itg3200: Use iio_push_to_buffers_with_timestamp()")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722155103.979802-6-jic23@kernel.org

iio:imu:st_lsm6dsx: check st_lsm6dsx_shub_read_output return

Potential error return is not checked.  This can lead to use
of undefined data.

Detected by clang static analysis.

st_lsm6dsx_shub.c:540:8: warning: Assigned value is garbage or undefined
        *val = (s16)le16_to_cpu(*((__le16 *)data));
             ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support")
Signed-off-by: Tom Rix <trix@redhat.com
Cc: <Stable@vger.kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200809175551.6794-1-trix@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: exynos_adc: Replace indio_dev->mlock with own device lock

As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock, to protect potential concurrent access to the
completion callback during a conversion.

This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200916093123.78954-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings:iio:adc:holt,hi8435 yaml conversion

Very simple binding.  I've changed the example to use the node
name threshold-detector@0 as sensor@0 seemed too generic.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Link: https://lore.kernel.org/r/20200909175946.395313-18-jic23@kernel.org

dt-bindings:iio:adc:adi,ad7768-1 yaml conversion

Fairly straight conversion.  The one oddity in the original binding
is that spi-cpha and spi-cpol were not marked as required, but were
in the example.  Looking at the datasheet, there isn't any documented
flexibility in the possible SPI modes, so I have moved these to requires.
For spi-max-frequency I have gone the other way.  I absolutely agree
that it is good to specify this in the dt-binding, but it's not
strictly required.

As Stefan's email is bouncing I have gone with Michael as maintainer
of this one as it falls under the ADI catch all entry in MAINTAINERS.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Link: https://lore.kernel.org/r/20200909175946.395313-16-jic23@kernel.org

dt-bindings:iio:adc:adi,ad7949 yaml conversion

Simple SPI driver. I've added the #io-channel-cells
as an optional parameter to allow use of this device as a provider
of ADC capabilities to other devices.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Link: https://lore.kernel.org/r/20200909175946.395313-15-jic23@kernel.org

dt-bindings:iio:adc:dlg,da9150-gpadc yaml conversion

This is a small part of an MFD so perhaps ultimately it makes more
sense to document it with that MFD binding rather than separately.

In the meantime it's a straightforward conversion from txt to yaml.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200909175946.395313-13-jic23@kernel.org

dt-bindings:iio:adc:motorola,cpcap-adc yaml conversion

Conversion from txt to yaml.
Slightly expanded example to give a bit more context.
Description lifted from the original driver commit.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200909175946.395313-12-jic23@kernel.org

dt-bindings:iio:adc:nxp,lpc3220-adc yaml conversion

Renamed to remove the wild cards.  These go wrong far too often so
in general preferred to use the name of a specific part.  As this
binding only provides one compatible, I went with that.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20200909175946.395313-11-jic23@kernel.org

dt-bindings:iio:adc:nxp,lpc1850-adc yaml conversion

Most of the description in the original doc is effectively boilerplate
and does not bring much value so I have not carried it over into the yaml.

Added #io-channel-cells to simplify use of channels on this ADC by
consumer drivers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Joachim Eastwood <manabian@gmail.com>
Link: https://lore.kernel.org/r/20200909175946.395313-10-jic23@kernel.org

dt-bindings:iio:adc:fsl,imx25-gcq yaml conversion

This binding has a few corners that would have been done different today
but hopefully the yaml schema captures the constraints correctly.

The child node names are not constrained hence the fairly open regexp.
I've also documented the defaults for the two references that the
driver seems to use and copied the value descriptions from the header
because I think they should be in the dt-binding itself.

This is part of a general effort to convert all the IIO bindings
over to yaml

Unfortunately I don't have a current address for Markus, so
have put myself as the maintainer for this binding until someone else
steps up!

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20200909175946.395313-21-jic23@kernel.org

dt-bindings:iio:adc:fsl,imx7d-adc yaml conversion

A nice simple binding.  Only real different from txt is that I dropped
some descriptions where the naming of the parameter was self explanatory

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Haibo Chen <haibo.chen@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20200909175946.395313-20-jic23@kernel.org

dt-bindings:iio:adc:ti,ads1015 yaml conversion

This binding was moved over from hwmon some time ago so is a bit
unusual in terms of IIO bindings.  However, conversion was fairly
straight forwards.

I've listed both Dirk (who think wrote original binding) and Daniel
who added the IIO driver for this device.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20200909175946.395313-17-jic23@kernel.org

dt-bindings:iio:adc:cosmic,10001-adc yaml conversion

I don't really know much about this one, hence the binding is
a simple conversion of what was in the txt file.

Note that I have taken on maintenance of this binding as I don't
have a recent address for Phani Movva.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200909175946.395313-14-jic23@kernel.org

dt-bindings:iio:adc:nuvoton,npcm750-adc yaml conversion

Renamed the file to reflect the only compatible.
Added #io-channel-cells to make it easier to support consumers of the
ADC channels this device provides.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Tomer Maimon <tmaimon77@gmail.com>
Link: https://lore.kernel.org/r/20200909175946.395313-9-jic23@kernel.org

dt-bindings:iio:adc:nuvoton,nau7802 yaml conversion

A simple conversion from txt file to yaml.  I added the #io-channel-cells
property as optional to allow the channels of this ADCs to be used
to provide services to other drivers, for example if an analog
accelerometer is connected.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20200909175946.395313-8-jic23@kernel.org

dt-bindings:iio:adc:sprd,sc2720-adc yaml conversion.

I changed the name to reflect a specific part in line with normal
naming conventions. If there is a particularly strong reason to
keep the wild cards let me know.

Otherwise this was a fairly simple conversion as part of converting
all the IIO bindings to yaml.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Orson Zhai <orsonzhai@gmail.com>
Cc: Baolin Wang <baolin.wang7@gmail.com>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20200909175946.395313-7-jic23@kernel.org

dt-bindings:iio:adc:marvell,berlin2-adc yaml conversion

Part of a general move of IIO bindings over to yaml.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>
Link: https://lore.kernel.org/r/20200909175946.395313-6-jic23@kernel.org

dt-bindings:iio:adc: aspeed,ast2400 yaml conversion

Simple txt to yaml conversion. Part of a general move to convert
all the IIO bindings over to yaml.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Joel Stanley <joel@jms.id.au>
Cc: Rick Altherr <raltherr@google.com>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20200909175946.395313-5-jic23@kernel.org

dt-bindings:iio:adc:st,stmpe-adc yaml conversion

Conversion from freeform text to yaml.
One oddity in this binding is that, for historical reasons it requires
the node name to be stmpe_adc.  I've put that in the decription field
but I'm not sure if there is a better way to specify this?

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Link: https://lore.kernel.org/r/20200909175946.395313-4-jic23@kernel.org

dt-bindings:iio:adc:ti,twl4030-madc yaml conversion

Conversion from txt to yaml as part of a general move of IIO bindings
to the new format.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Sebastian Reichel <sre@kernel.org>
Link: https://lore.kernel.org/r/20200909175946.395313-3-jic23@kernel.org

dt-bindings:iio:adc:fsl,vf610-adc conversion to yaml.

A simple conversion of this freescale ADC binding from txt to yaml.
For maintainer I went with Fugang Duan as the original author of the
binding. Would be great to have confirmation of this.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20200909175946.395313-2-jic23@kernel.org

iio: imu: st_lsm6dsx: Scaling factor type set to IIO_VAL_INT_PLUS_NANO

Scaling factor values for Acc lead to an unacceptable rounding of the
full scale (FS) calculated by some SensorHAL on Android devices. For examples
setting FS to 4g the in_accel_x_scale, in_accel_y_scale and in_accel_z_scale
are 0.001196 on 6 decimal digits and the FS is
0.001196 × ((2^15) − 1) ~= 39.1893 m/s^2.

Android CTS R10 SensorParameterRangeTest test expects a value greater than
39.20 m/s^2 so this test fails (ACCELEROMETER_MAX_RANGE = 4 * 9.80).

Using 9 decimal digits the new scale factor is 0.001196411 and the FS now
is 0.001196411 × ((2^15)−1) ~= 39.2028 m/s^2.

This patch extends to IIO_VAL_INT_PLUS_NANO type the scaling factor to all
IMU devices where SensorParameterRangeTest CTS test fails.

Signed-off-by: Mario Tesi <mario.tesi@st.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/1600361236-2285-1-git-send-email-martepisa@gmail.com

iio: adis. Drop adis_burst struct

As there are no users anymore of this structure, it can be safely
removed.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200917155223.218500-5-nuno.sa@analog.com

iio: adis16475: Drop adis_burst usage

Burst mode variables are now part of the `adis_data` struct. The driver
also has now to explicitly define the length of the burst buffer.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200917155223.218500-4-nuno.sa@analog.com

iio: adis16400: Drop adis_burst usage

Burst mode variables are now part of the `adis_data` struct. The driver
also has now to explicitly define the length of the burst buffer.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200917155223.218500-3-nuno.sa@analog.com

iio: adis: Move burst mode into adis_data

Add burst mode variables in the per device specific data structure. As
some drivers support multiple devices with different burst sizes it
makes sense this data to be in `adis_data`. While moving the variables,
there are two main differences:

1. The `en`variable is dropped. If a device supports burst mode, it will
just use it as it will has better performance for almost all real use
cases.
2. Replace `extra_len` by `burst_len`. Users should now explicitly
define the length of the burst buffer as it is typically constant. This
also allows to remove the following line from the library:

```
/* All but the timestamp channel */
burst_length = (indio_dev->num_channels - 1) * sizeof(u16);
```

The library should not assume that a timestamp channel is defined.
Moreover, most parts also include some diagnostic data, crc, etc.. in
the burst buffer that needed to be included in an `extra_len` variable
which is not that nice. On top of this, some devices already start to
have some 32bit size channels ...

This patch is also a move to completely drop the `struct adis_burst`
from the library.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200917155223.218500-2-nuno.sa@analog.com

iio:accel:bma180: Fix use of true when should be iio_shared_by enum

Given a value of 1 corresponds to IIO_SHARE_BY_TYPE I have replaced
it with that.  Should cause no functional change.

Fixes: fdadbce0da42 ("iio: add Bosch BMA180 acceleration sensor driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Jonathan Bakker <xc-racer2@live.ca>
Link: https://lore.kernel.org/r/20200913121227.764626-1-jic23@kernel.org

iio:magn:hmc5843: Fix passing true where iio_shared_by enum required.

So it's obvious that the code is wrong in passing true, but I'm assuming
that will actually evaluate to 1 and hence IIO_SHARED_BY_TYPE.
The documentation however has this attribute as IIO_SHARED_BY_ALL.
My current assumption is the documentation is wrong.
If anyone knows otherwise please shout out!

Fixes: 7247645f6865 ("iio: hmc5843: Move hmc5843 out of staging")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/20200913112546.715624-1-jic23@kernel.org

iio: Add __printf() attributes to various allocation functions

A partial set of these was added to IIO a long time back.
This fills in some gaps in coverage highlighted by building
with W=1

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200913132115.800131-3-jic23@kernel.org

iio:core: Tidy up kernel-doc.

One comment isn't kernel-doc at all, but starts with /** and another
is simply missing a parameter that was introduced recently.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200913132115.800131-4-jic23@kernel.org

iio: dac: ad5592r: localize locks only where needed in ad5592r_read_raw()

Since there was a recently discovered issue with these locks, it probably
makes sense to cleanup the code a bit, to prevent it from being used as an
example/reference.

This change moves the lock only where it is explicitly needed to protect
resources from potential concurrent accesses.

It also reworks the switch statements to do direct returns vs caching the
return value on a variable.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200706110259.23947-3-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad5592r: un-indent code-block for scale read

The next rework may require an unindentation of a code block in
ad5592r_read_raw(), which would make review a bit more difficult.

This change unindents the code block for reading the scale of the
non-temperature channels.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200706110259.23947-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:dac:ad5592r: Fix use of true for IIO_SHARED_BY_TYPE

struct iio_chan_spec_ext_info shared element is of type
enum iio_shared_by, not boolean.   It's like the enum value
will for IIO_SHARED_BY_TYPE == 1 == true, hence no actual
problem has been observed.

  CC [M]  drivers/iio/dac/ad5592r-base.o
  491 |   .shared = true,
      |

Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200722142515.897378-1-jic23@kernel.org

iio: chemical: sgp30: Add description for sgp_read_cmd()'s 'duration_us'

Fixes the following W=1 kernel build warning(s):

 drivers/iio/chemical/sgp30.c:236: warning: Function parameter or member 'duration_us' not described in 'sgp_read_cmd'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Andreas Brauchli <a.brauchli@elementarea.net>
Cc: Pascal Sachs <pascal.sachs@sensirion.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-6-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: gyro: adis16080: Fix formatting issue

Kerneldoc expects attributes/parameters to be in '@*.: ' format.

Fixes the following W=1 kernel build warning(s):

 drivers/iio/gyro/adis16080.c:49: warning: Function parameter or member 'lock' not described in 'adis16080_state'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Barry Song <21cnbao@gmail.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-13-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dummy: iio_dummy_evgen: Demote file header and supply description for 'irq_sim_domain'

File headers are not good candidates for kerneldoc.

Fixes the following W=1 kernel build warning(s):

 drivers/iio/dummy/iio_dummy_evgen.c:30: warning: Cannot understand  * @regs: irq regs we are faking
 on line 30 - I thought it was a doc line
 drivers/iio/dummy/iio_dummy_evgen.c:42: warning: Function parameter or member 'irq_sim_domain' not described in 'iio_dummy_eventgen'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-16-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7949: Fix misspelling issue

Fixes the following W=1 kernel build warning(s):

 drivers/iio/adc/ad7949.c:58: warning: Function parameter or member 'indio_dev' not described in 'ad7949_adc_chip'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-18-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad5064: Fix a few kerneldoc misdemeanours

Misspelling, missing description.

Fixes the following W=1 kernel build warning(s):

 drivers/iio/dac/ad5064.c:71: warning: bad line:                         internal vref.
 drivers/iio/dac/ad5064.c:83: warning: Function parameter or member 'channels' not described in 'ad5064_chip_info'
 drivers/iio/dac/ad5064.c:125: warning: Function parameter or member 'lock' not described in 'ad5064_state'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200716135928.1456727-20-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad7303: Complete 'struct ad7303_state' doc

Fixes the following W=1 kernel build warning(s):

 drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vdd_reg' not described in 'ad7303_state'
 drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vref_reg' not described in 'ad7303_state'
 drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'lock' not described in 'ad7303_state'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200716135928.1456727-31-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: fsl-imx25-gcq: Replace indio_dev->mlock with own device lock

As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock, to protect against any other accesses during the
reading of sample. Reading a sample requires multiple consecutive regmap
operations and a completion callback, so this requires that no other
read occurs until it completes.

This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916092928.78026-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: proximity: vl53l0x: Add IRQ support

VL53L0X can be configured to use interrupt pin (GPIO1)
to notify host about readiness of new measurement.

If interrupt pin is not specified, driver still uses polling.

Signed-off-by: Ivan Drobyshevskyi <drobyshevskyi@gmail.com>
Link: https://lore.kernel.org/r/20200916074458.873359-2-drobyshevskyi@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: proximity: vl53l0x: Add IRQ support

Since IRQ support was added to the driver, update bindings accordingly.

Signed-off-by: Ivan Drobyshevskyi <drobyshevskyi@gmail.com>
Link: https://lore.kernel.org/r/20200916074458.873359-1-drobyshevskyi@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:health:max30102: Drop of_match_ptr and use generic fw accessors

This enables use of the driver with ACPI PRP0001 and also removes
an antipattern that I am trying to clear out of IIO to avoid
it being copied into new drivers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-39-jic23@kernel.org

iio:humidity:si7020: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: David Barksdale <dbarksdale@uplogix.com>
Link: https://lore.kernel.org/r/20200910173242.621168-38-jic23@kernel.org

iio:humidity:htu21: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-37-jic23@kernel.org

iio:magn:ak8974: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200910173242.621168-36-jic23@kernel.org

iio:magn:ak8975: Drop of_match_ptr and ACPI_PTR protections.

Both would result in only a small size saving.  For simplicity it
is best to remove them.  I also wish to remove both these antipatterns
from IIO.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-35-jic23@kernel.org

iio:proximity:pulsedlight: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-34-jic23@kernel.org

iio:proximity:as3935: Drop of_match_ptr and use generic fw accessors

This change allows the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-33-jic23@kernel.org

iio:proximity:as3935: Use local struct device pointer to simplify code.

This makes the existing code easier to read and will make the following
patch a little simpler.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-32-jic23@kernel.org

iio:humidity:hdc100x: Drop of_match_ptr protection.

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-31-jic23@kernel.org

iio:chemical:vz89x: Drop of_match_ptr protection and use generic fw accessors

This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.

The handling of match_data uses a different approach as
device_get_match_data() doesn't distinguish between no match, and
a match but with NULL data.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-30-jic23@kernel.org

iio:chemical:vz89x: Introduce local struct device pointer.

Avoids lots of repetition of &client->dev and will make the next
patch tidier.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-29-jic23@kernel.org

iio:chemical:sgp30: Drop of_match_ptr and use generic fw accessors

This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.

The handling of match_data uses a different approach as
device_get_match_data doesn't distinguish between no match, and
a match but with NULL data.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20200910173242.621168-28-jic23@kernel.org

iio:chemical:sgp30: Use local variable dev to simplify code

This cleans up the code at bit, but is primarily here as a precusor
to the next patch. I've only done this for the two functions
which use the dev pointer repeatedly.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20200910173242.621168-27-jic23@kernel.org

iio:chemical:atlas-sensor: Drop of_match_ptr and use generic fw accessors

of_match_ptr() prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver and use generic fw accessors to check
if there is a fw_node and get the id.

It might be neater to use pointers rather than indexes for
the device_data but that is another issue and should be handled
separately.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-26-jic23@kernel.org

iio:chemical:ams-iaq-core: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-25-jic23@kernel.org

iio:resolver:ad2s1200: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-24-jic23@kernel.org

iio:temperature:tmp007: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Manivannan Sadhasivam <manivannanece23@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-23-jic23@kernel.org

iio:temperature:tsys01: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-22-jic23@kernel.org

iio:pressure:zpa2326: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Link: https://lore.kernel.org/r/20200910173242.621168-21-jic23@kernel.org

iio:pressure:ms5637: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-20-jic23@kernel.org

iio:pressure:ms5611: Drop of_match_ptr and CONFIG_OF protections

These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Tomasz Duszynski <tduszyns@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-19-jic23@kernel.org

iio:pressure:icp10100: Drop of_match_ptr and CONFIG_OF protections

These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20200910173242.621168-18-jic23@kernel.org

iio:potentiostat:lmp91000: Drop of_match_ptr and use generic fw accessors

This change allows use of this driver with ACPI via PRP0001 and removes
an example of an anti pattern I'm trying to remove from IIO.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-17-jic23@kernel.org

iio:dac:ti-dac5571: Drop of_match_ptr and CONFIG_OF protections

These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Link: https://lore.kernel.org/r/20200910173242.621168-16-jic23@kernel.org

iio:dac:ti-dac082s085: Drop of_match_ptr and CONFIG_OF protections

These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20200910173242.621168-15-jic23@kernel.org

iio:dac:mcp4725: drop of_match_ptr and use generic fw properties

This enables use of ACPI PRP0001 and removes an antipattern I am
trying to stop people copying in IIO.

This particular case is more complex than most because it allowed
probing via sysfs with out a fwnode but would presumably always
have then failed.   Now the code will assume that properties are
the defaults if not specified or the firmware node is not present.
This relaxation of the constraints should not break any existing
cases and may enable some new ones.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Link: https://lore.kernel.org/r/20200910173242.621168-14-jic23@kernel.org

iio:dac:ad7303: Drop of_match_ptr protection

This prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.

Also add mod_devicetable.h include given struct of_device_id is
declared there.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-13-jic23@kernel.org

iio:dac:ad5593r: Drop of_match_ptr and ACPI_PTR protections.

These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification.  In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices.  That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-12-jic23@kernel.org

iio:dac:ad5592r: Drop of_match_ptr and ACPI_PTR protections.

These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification.  In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices.  That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-11-jic23@kernel.org

iio:dac:ad5446: Drop of_match_ptr and CONFIG_OF protections

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20200910173242.621168-10-jic23@kernel.org

iio:potentiometer:mcp4531: Drop of_match_ptr and CONFIG_OF protections.

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.

Also switch to device_get_match_data() from of_ variant and adjust
headers to reflect the change.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200910173242.621168-9-jic23@kernel.org

iio:potentiometer:mcp4131: Drop of_match_ptr and use generic fw interfaces.

This change allows the use of the driver with ACPI via PRP0001
and remove an example of an anti pattern I'm trying to remove from IIO.
Also adjust includes to reflect this change.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-8-jic23@kernel.org

iio:potentiometer:mcp4018: Drop of_match_ptr and CONFIG_OF protections.

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also use device_get_match_data() rather than devicetree only version.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200910173242.621168-7-jic23@kernel.org

iio:potentiometer:max5481: Drop invalid ACPI binding.

Given that an ACPI binding must start with 3 or 4 capitals,
this cannot represent a valid binding.

It seems unlikely anything out there is using it.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Maury Anderson <maury.anderson@rockwellcollins.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-6-jic23@kernel.org

iio:potentiometer:max5481: Drop of_match_ptr and CONFIG_OF protections.

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Whilst this driver has an ACPI binding, it is not of a form
that is valid under ACPI so will be dropped shortly.

Also switch to device_get_match_data() and switch headers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Maury Anderson <maury.anderson@rockwellcollins.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-5-jic23@kernel.org

iio:potentiometer:max5432: Drop of_match_ptr and use generic fw accessors

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.

Also switch headers to reflect this change.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20200910173242.621168-4-jic23@kernel.org

iio:potentiometer:ds1803: Drop of_match_ptr and CONFIG_OF protections

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.

Also switch of.h for mod_devicetable.h include given use of
struct of_device_id which is defined in that header.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-3-jic23@kernel.org

iio:potentiometer:ad5272: Drop of_match_ptr and CONFIG_OF protections.

These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.

Also added mod_devicetable.h include given use of struct of_device_id
which is defined in that header.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Phil Reid <preid@eletromag.com.au>
Link: https://lore.kernel.org/r/20200910173242.621168-2-jic23@kernel.org

iio:imu:adis16400: Sort out missing kernel doc.

I'd like to be enable W=1 for all IIO builds as it catches real issues as well
as more minor documentation issues such as this (also good to fix though!)

drivers/iio/imu/adis16400.c:183: warning: Function parameter or member 'avail_scan_mask' not described in 'adis16400_state'

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200913132115.800131-2-jic23@kernel.org

iio: buffer: split buffer sysfs creation to take buffer as primary arg

Currently the iio_buffer_{alloc,free}_sysfs_and_mask() take 'indio_dev' as
primary argument. This change splits the main logic into a private function
that takes an IIO buffer as primary argument.

That way, the functions can be extended to configure the sysfs for multiple
buffers.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200917125951.861-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: meson-saradc: Make the of_device_id array style consistent

Use only one line for the closing bracket of the last entry and the
opening bracket for the next one to keep the style across the whole
array consistent. Also add a "sentinel" comment to the last entry and
remove the comma to ensure that there won't be any entry after it.
No functional changes.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20200915192621.13202-1-martin.blumenstingl@googlemail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad9467: return ENODEV vs EINVAL in ad9467_setup()

The proper error code should be ENODEV (vs EINVAL) in case the chip ID
isn't recognized.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916082221.72851-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad9467: refine mismatch vs unknown chip-id messages

We should probably print what the expected chip-ID is. We already have
that information available, based on the device specified via
device-tree.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916083128.73729-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

staging:iio:documentation: Drop most generic docs

These docs are both suffering from being out of date, and from being
superceeded by the documentation in Documentation/driver-api/iio

Note the inkern.txt drop is left for now as this is an area not
well covered by the more recent documentation outside staging.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200905174721.216452-5-jic23@kernel.org

staging:iio:light: drop stale ABI docs

There are no remaining light drivers in staging/iio.
The content of this file are either included in the non staging
ABI docs, or don't seem to be used in any current driver.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200905174721.216452-4-jic23@kernel.org

staging:iio:light: Move tsl2x7x ABI docs to correct location.

These seem to be up to date but never moved out of staging when the driver
did. Hence let us move them out now.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Brian Masney <masneyb@onstation.org>
Cc: Brian Masney <masneyb@onstation.org>
Link: https://lore.kernel.org/r/20200905174721.216452-3-jic23@kernel.org

staging:iio:dac:max517 remove documentation

Whilst there is some useful info in here, it can be easily
obtained from datasheets. Some of the info should perhaps
be incorporated into a device tree bindings doc.
As this didn't move out of staging with the driver, I'm suggesting
we just drop it.  We don't generally carry per driver documentation
with the exception of non standard ABI which is not the case here.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Roland Stigge <stigge@antcom.de>
Link: https://lore.kernel.org/r/20200905174721.216452-2-jic23@kernel.org

iio: adc: palmas_gpadc: use module_platform_driver to simplify the code

module_platform_driver() makes the code simpler by eliminating
boilerplate code.

Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Link: https://lore.kernel.org/r/20200914065401.3726354-1-liushixin2@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adis: Drop non Managed device functions

Drop `adis_setup_buffer_and_trigger()`. All users were updated to use
the devm version of this function. This avoids having almost the same
code repeated.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-11-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

staging: iio: adis16240: Use Managed device functions

Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.

Since we are here, drop the `.remove` callback by further using devm
functions.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-10-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>