Continuing from Alexandru Ardelean's introduction of the split between
driver modifiable fields and those that should only be set by the core.

This could have been done in two steps to make the actual move after
introducing iio_device_id() but there seemed limited point to that
given how mechanical the majority of the patch is.

Includes fixup from Alex for missing mxs-lradc-adc conversion.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org

This is already set to the same value in devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jyoti Bhayana <jbhayana@google.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-9-jic23@kernel.org

iio_dev.dev.parent is already set to the same value in
devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Ye Xiang <xiang.ye@intel.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-8-jic23@kernel.org

Already set to same value in devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Eugene Zaikonnikov <ez@norphonic.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-7-jic23@kernel.org

Already set to same value in devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Tomislav Denis <tomislav.denis@avl.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-6-jic23@kernel.org

Already set to the same value in devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Gene Chen <gene_chen@richtek.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-5-jic23@kernel.org

This is already set to the same value in devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Saravanan Sekar <sravanhome@gmail.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-4-jic23@kernel.org

This is set to the same value in devm_iio_device_alloc() so no need to do
it again.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Cristian Pop <cristian.pop@analog.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-3-jic23@kernel.org

The core already set this to the same value in devm_iio_device_alloc()
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426170251.351957-2-jic23@kernel.org

Basically the TI TSC2046 touchscreen controller is 8 channel ADC optimized for
the touchscreen use case. By implementing it as an IIO ADC device, we can
make use of resistive-adc-touch and iio-hwmon drivers.

Polled readings are currently not implemented to keep this patch small, so
iio-hwmon will not work out of the box for now.

So far, this driver was tested with a custom version of resistive-adc-touch driver,
since it needs to be extended to make use of Z1 and Z2 channels. The X/Y
are working without additional changes.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210428073208.19570-4-o.rempel@pengutronix.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add a binding documentation for the TI TSC2046 touchscreen controllers
ADC functionality.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210428073208.19570-3-o.rempel@pengutronix.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Settling time and over sampling is a typical challenge for different IIO ADC
devices. So, introduce channel specific settling-time-us and oversampling-ratio
properties to cover this use case.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210428073208.19570-2-o.rempel@pengutronix.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Commit 63cd35f3 ("iio: Documentation: update definitions for bufferY and scan_elements")
updated iio documentation in order to point to the newly
per-buffer API, as it is now possible to support multi buffers.

While the previous ABI will be kept forever, the best is
for applications to use the 5.11+ ABI. So, move the
legacy one ABI/obsolete.

This fixes an issue with scripts/get_abi.pl, that doesn't
accept two different Kernel version support for the same
API set.

Fixes: 63cd35f3 ("iio: Documentation: update definitions for bufferY and scan_elements")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/a2c802049adee6a5710a58082cfdc1132c5e4c11.1619532170.git.mchehab+huawei@kernel.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

W=1 highlights these two cases that are obviously not in kernel-doc
format.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: NFabrice Gasnier <fabrice.gasnier@foss.st.com>

sps30 has gained support for serial communication so add example to the
binding file. While at it remove reg property from list of required
properties because it's no-op in case of serial communication.
Signed-off-by: NTomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Sensor has support for both i2c and serial communication interfaces.
Both offer very similar set of features. Minor differences don't impact
overall functionality like doing measurements, etc.

Support for i2c have already been added, this patch adds support
for the latter ie. serial interface.
Signed-off-by: NTomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Move code responsible for handling i2c communication to a separate file.
Rationale for this change is preparation for adding support for serial
communication.
Signed-off-by: NTomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The adf4371 has channels that are very closely coupled, so additional
documentation is needed to express these constraints.
Unfortunately having the same sysfs filename in multiple documentation
does not work well when generating automated documentation.
To avoid this issue, we add a new device specific description to the
main docs and remove the one in the device specific file.

Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:0  ./Documentation/ABI/testing/sysfs-bus-iio:599

Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reported-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-8-jic23@kernel.org

This one is challenging as both the places this appears in specific drivers
are making 'unusual' uses of what looks like a simple output current
channel.
As a side note, this was particular bit of ABI occurs in other drivers
where the use is much more straight forward e.g. dac/ad5421

This patch attempts to make a best effort of adding it to the main docs but
retaining enough information. Both of these drivers probably need
specific documents being written to describe their unusual interfaces, but
those should be in the main documentation, not under Documentation/ABI.
That is a non trivial job so left for another time.

Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als:43  ./Documentation/ABI/testing/sysfs-bus-iio-health-afe440x:38
Reported-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-5-jic23@kernel.org

The interface is standard and the extra info provided on exactly what is
being powered down is not of interest to most users.  Hence this doesn't
need it's own documentation and can rely on the docs in sysfs-bus-iio

Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:36  ./Documentation/ABI/testing/sysfs-bus-iio:588

Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reported-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-4-jic23@kernel.org

This device has the unusual characteristic that the calibbias values
have well defined units (more commonly they are tweaks to a DAC)
Unfortunately the previous approach of having more specific documentation
in sysfs-bus-iio-icm42600 results in warnings during the documentation
build and random ordering in the resulting documentation.

To avoid this, add a note to the main documentation on this special
characteristic for the icm42600.   The _available for calibbias was
missing from the main sysfs-bus-iio docs so also add that, allowing
us to drop the icm42600 specific file.

Fixes
$ scripts/get_abi.pl validate warning:
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:0  ./Documentation/ABI/testing/sysfs-bus-iio:394
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:1  ./Documentation/ABI/testing/sysfs-bus-iio:395
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:2  ./Documentation/ABI/testing/sysfs-bus-iio:396
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:3  ./Documentation/ABI/testing/sysfs-bus-iio:397
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:4  ./Documentation/ABI/testing/sysfs-bus-iio:398
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias is defined 2 times:  ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:5  ./Documentation/ABI/testing/sysfs-bus-iio:399

Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Reported-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-2-jic23@kernel.org

With commit 3ba10e37371d ("iio: adis: add burst_max_speed_hz variable"), we
just need to define 'burst_max_speed_hz' and the adis core will take
care of setting up the spi transfers for burst mode. Hence, we fix
a potential race with the spi core where we could be left witn an
invalid 'max_speed_hz'.
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Fixes: 5eda3550 ("staging:iio:adis16400: Preallocate transfer message")
Signed-off-by: NNuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-7-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

With commit 3ba10e37371d ("iio: adis: add burst_max_speed_hz variable"), we
just need to define 'burst_max_speed_hz' and the adis core will take
care of setting up the spi transfers for burst mode. Hence, we fix
a potential race with the spi core where we could be left with an
invalid 'max_speed_hz'.
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Fixes: fff7352b ("iio: imu: Add support for adis16475")
Signed-off-by: NNuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-6-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Typically, in burst mode, the device cannot operate at it's full spi
speed. Hence, the spi transfers for burst mode have to take this into
account. With this change we avoid a potential race with the spi core as
drivers were 'hacking' the device 'max_speed_hz' directly in the
trigger handler.
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: NNuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-5-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

There's no point in pushing data to IIO buffers in case 'spi_sync()'
fails.
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: NNuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-4-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

It makes more sense to update the device page as soon as we we
successfully changed it. Moreover, a follow up patch will handle
'spi_sync' error path which would leave 'current_page' in a inconsistent
state.
Signed-off-by: NNuno Sa <nuno.sa@analog.com>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210427085454.30616-3-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

On an IRQ handler we should not return normal error codes as 'irqreturn_t'
is expected.

This is done by jumping to the 'check_burst32' label where we return
'IRQ_HANDLED'. Note that it is fine to do the burst32 check in this
error path. If we have proper settings to apply burst32, we might just
do the setup now so that the next sample already uses it.

Fixes: fff7352b ("iio: imu: Add support for adis16475")
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: NNuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-2-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add initial support for Murata SCA3300 3-axis industrial
accelerometer with digital SPI interface. This device also
provides a temperature measurement.

Datasheet: https://www.murata.com/en-global/products/sensor/accel/sca3300Signed-off-by: NTomas Melin <tomas.melin@vaisala.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210426081041.59807-3-tomas.melin@vaisala.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

initial DT bindings for Murata SCA3300 Accelerometer.
Signed-off-by: NTomas Melin <tomas.melin@vaisala.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210426081041.59807-2-tomas.melin@vaisala.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This binding covers class of simple SPI ADCs which only provide
data output - they don't have MOSI pin.

The only real variation between them is over how many supplies they
use and which one is used for the reference.

Michael listed as maintainer for this one as it is his driver and
falls under the catch all MAINTAINERS entry for ADI devices.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210425163154.73209-3-jic23@kernel.org

Not all of the parts supported by this driver use single supply.
Hence we add chip_info fields to say what additional supplies exist
and in the case of vref, ensure that is used for the reference voltage
rather than vcc.

One corner case is the ad7091r which has an internal reference that
can be over-driven by an external reference connected on the vref pin.
To handle that force_ext_vref is introduced and set if an optional
vref regulator is present.

Tested using really simple QEMU model and some fixed regulators.

The devm_add_action_or_reset() callback is changed to take the
regulator as it's parameter so we can use one callback for all the
different regulators without having to store pointers to them in
the iio_priv() structure.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210425163154.73209-2-jic23@kernel.org

Fairly simple conversion with the exception of the XOR between
spi-cpha and spi-cpol.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20201031134110.724233-17-jic23@kernel.orgReviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401140956.224084-3-jic23@kernel.org

These are never upper case.  Chances are that all users of this driver
were using the ACPI binding but just in case keep the uppercase version
but mark it deprecated.

Whilst here tidy up some spacing.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210401144226.225928-1-jic23@kernel.org

The device has a tsens-busy pin, but it's both fiddly and currently
ignored by the Linux driver.  Given it's not clear whether the binding
should be an interrupt, or a GPIO I have left that out for now.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401174112.320497-7-jic23@kernel.org

Two simple devices. The stk8ba50 datasheet could be found via
google, but I only have the driver for the 8312.

Given they both seem to be 3 axis devices with a single interrupt
line, add them to trivial-devices.yaml
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401174112.320497-6-jic23@kernel.org

Simple devices with I2C interface and single interrupt line so
entries in trivial devices are sufficient.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401174112.320497-5-jic23@kernel.org

Binding documentation for this driver was missing.
Note that the binding and some in tree dts files specifiy interrupts
etc but the driver is fairly simple and does not yet make use of them.

Listed both Joachim and myself as maintainers for this binding on basis
it's Joachim's driver but I don't want to volunteer Joachim too
strongly to look after this doc.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401174112.320497-4-jic23@kernel.org

Linux driver currently relies on the driver.name to match to the
compatible, but that doesn't mean it isn't a good idea to document it.

Only real complexity is the 3 separate power supplies.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401174112.320497-3-jic23@kernel.org

These two devices have different internal characteristics, but their
external connectivity and as a result device tree descriptions are
identical.

Note that neither driver in Linux currently has an of_match_table
but instead rely on matching via name alone.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210401174112.320497-2-jic23@kernel.org

Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NNuno Sa <nuno.sa@analog.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1617881896-3164-8-git-send-email-yangyicong@hisilicon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>