iio:adc:ingenic: drop of_match_ptr protection and include mod_devicetable.h

Whilst it's unlikely this device will ever be instantiated using
ACPI, there is little advantage not assigning the of_device_id table in all
cases and it avoids providing an example that might be coppied into new
drivers.

Also include mod_devicetable.h whilst here as of_device_id is defined
in there so including the header is best practice.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Artur Rojek <contact@artur-rojek.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ti-tlc4541: Drop CONFIG_OF and of_match_ptr protections.

These stop us using ACPI PRP0001 to instantiate the device.
I am slowly clearly out use of these in IIO to avoid this being coppied
into new drivers.

Here I also included mod_devicetable.h as we are using of_match_id
which is defined in there and hence it is best practice to include
it directly.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Phil Reid <preid@electromag.com.au>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ti-adc161s626: Drop of_match_ptr protection.

Dropping this allows use of ACPI PRP0001.

I'm also looking to drop all of_match_ptr use in IIO in order to avoid
it getting cut and paste into new drivers in the future.

Also add a direct include of mod_devicetable.h to reflect the use
of struct of_device_id.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ti-adc084s021: drop of_match_ptr protection

Allows ACPI PRP0001 to be used with this driver.
Also adds mod_devicetable.h header as the driver is directly using
struct of_device_id which is defined in that file.

I'm also trying to clear out of_match_ptr use in IIO to avoid it
being cut and paste into new drivers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mårten Lindahl <martenli@axis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ti-adc0832: drop CONFIG_OF and of_match_ptr protections

These just prevent the driver being used with ACPI PRP0001.

I am also trying to remove these from IIO in general to avoid
them being coppied into new drivers.

Also include the mod_devicetable.h header as we are using
of_device_id which is defined in there.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ti-adc081c: Drop of_match_ptr and change to mod_devicetable.h

Whilst this driver already supports explicit ACPI bindings we
might as well also allow for PRP0001 based binding.

I'm also keen to remove of_match_ptr from IIO drivers to avoid
this (now) anti-pattern getting coppied into new drivers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:sd_adc_modulator: Drop of_match_ptr and tweak includes

Dropping of_match_ptr allows this driver to be used with ACPI.
The header includes are adjusted to include platform_device.h
and mod_devicetable.h instead of OF specific header as nothing
from that header itself is actually used.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:mcp3422: remove CONFIG_OF and of_match_ptr protections

They stop the driver being used with ACPI PRP0001 and are something
I want to avoid being cut and paste into new drivers.
Also switch the include from of.h to mod_devicetable.h as we
struct of_device_id is defined in there and we don't use anything
actually in of.h.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:mcp320x: Drop CONFIG_OF and of_match_ptr protections

These just prevent the driver being used with ACPI PRP0001.
They also get cut and paste into new drivers and we want to discourage
this from happening by cleaning it out in general.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Oskar Andero <oskar.andero@gmail.com>
Cc: Søren Andersen <san@rosetechnology.dk>
Cc: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:max1118: Drop CONFIG_OF / of_match_ptr protections

These just stop the driver being used with ACPI PRP0001 and
we are trying to clear them out of IIO to avoid them getting copied
into new drivers.
Also add the mod_devicetable.h include as we are using
struct of_device_id which is defined in there.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:max11100: Drop of_match_ptr protection / add mod_devicetable.h include

Allows use of driver with ACPI PRP0001 base binding.
Mostly this is about trying to avoid cut and paste of this into new
drivers (it is a frequent review comment) rather than any
thought that this driver might get used on an ACPI platform.

The mod_devicetable.h include is to encourage best practice of including
any header directly used within the code (here for of_match_id)

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ltc2497 drop of_match_ptr protection

This prevents the driver being used with ACPI PRP0001 based
bindings. Also switch include to mod_devicetable.h which devices
the used id structure.

Note this is most about removing something I don't want want cut
and paste into new driver rather than any thought that this particular
driver will be used in an ACPI system (though it might!)

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:cpcap-adc: Drop of_match_ptr protection and use device_get_match_data

Part of a slow effort to avoid OF specific code in IIO.

Whilst the main advantages of this are not likely to be seen in this
particular driver (ACPI support via PRP0001) the change proposed
does make things a bit more maintainable and also ensures that
this particular (now) anti-patern is less likely to be cut and
paste into new drivers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ltc2496: Drop of_match_ptr and use mod_devicetable.h

The macro prevents use of driver with ACPI PRP0001 and
the of_match_id structure is defined in mod_devicetable.h so include
that directly rather than of.h.

Note this is mostly about removing something I don't want cut and
paste into new drivers rather than expectation that this particular
driver will be used on an ACPI platform.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:max1027: drop of_match_ptr and CONFIG_OF protections

These just prevent the driver being used with ACPI PRP0001
and provide no major benefits.

Part of clearing these out in general in IIO to avoid cut and paste
repetition in new drivers.  Also include mod_devicetable.h as we
directly make use of of_device_id which is defined in there.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:max1363: Drop of_match_ptr and use generic device_get_match_data

Allows driver to use ACPI PRP0001 binding and there was no particular
advantage in having the protections in this driver.

Mostly this part of an effort to remove as many OF specific bits
of handling from IIO and use the generic forms where possible.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:hi8435: Drop of_match_ptr protection.

Allows use of ACPI with PRP0001 and is generally something we are
trying to avoid having people cut and paste into new drivers without
thinking about it.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:hi8435: Drop unused of_gpio.h header

I guess this is a left over from some earlier cleanup. Not used
currently.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:lpc32xx: Drop of_match_ptr protection

Whilst is unlikely anyone will be using this part with an ACPI PRP0001
based binding any time soon, we are getting a lot of cut and pasting
of this pattern so I am looking to remove it entirely from IIO.

In this case CONFIG_OF protections also removed and
mod_devicetable.h include added given direct use of struct of_device_id.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio: magnetometer: bmc150: Add proper compatible for BMM150

The compatible for BMM150 should not have "_magn" suffix because, unlike
two other Bosch devices, it is only a magnetometer.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: bmc150_magn: Document and fix missing compatibles

The driver supports also BMC156B and BMM150B.  Add existing compatibles
marking the BMM150B one as deprecated (due to redundant suffix "_magn"
because the device unlike two others is a magnetometer only).  Introduce
a new, proper compatible for the deprecated one.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adis16480: Use irq types instead of flags

The value retrieved by `irqd_get_trigger_type()` is not an irq flag.
While the values are the same, the meaning is different.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation/driver-api: iio/buffers: drop doubled word

Drop the doubled word "struct".

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation/driver-api: generic-counter: drop doubled word

Drop the doubled word "the".

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: move event interface on the opaque struct

Same as with other private fields, this moves the event interface reference
to the opaque IIO device object, to be invisible to drivers.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: move iio_dev's buffer_list to the private iio device object

This change moves the 'buffer_list' away from the public IIO device object
into the private part.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: move channel list & group to private iio device object

This change bit straightforward and simple, since the
'channel_attr_list' & 'chan_attr_group' fields are only used in
'industrialio-core.c'.

This change moves to the private IIO device object

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: move debugfs data on the private iio dev info

This change moves all iio_dev debugfs fields to the iio_dev_priv object.
It's not the biggest advantage yet (to the whole thing of abstractization)
but it's a start.

The iio_get_debugfs_dentry() function (which is moved in
industrialio-core.c) needs to also be guarded against the CONFIG_DEBUG_FS
symbol, when it isn't defined. We do want to keep the inline definition in
the iio.h header, so that the compiler can better infer when to compile out
debugfs code that is related to the IIO debugfs directory.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: remove padding from private information

There was a recent discussion about this code:
  https://lore.kernel.org/linux-iio/20200322165317.0b1f0674@archlinux/

This looks like a good time to removed this, since any issues about it
should pop-up under testing, because the iio_dev is having a bit of an
overhaul and stuff being moved to iio_dev_opaque.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: wrap IIO device into an iio_dev_opaque object

There are plenty of bad designs we want to discourage or not have to review
manually usually about accessing private (marked as [INTERN]) fields of
'struct iio_dev'.

Sometimes users copy drivers that are not always the best examples.

A better idea is to hide those fields into the framework.
For 'struct iio_dev' this is a 'struct iio_dev_opaque' which wraps a public
'struct iio_dev' object.

In the next series, some fields will be moved to this new struct, each with
it's own rework.

This rework will not be complete-able for a while, as many fields need some
drivers to be reworked in order to finalize them (e.g. 'indio_dev->mlock').

But some fields can already be moved, and in time, all of them may get
there (in the 'struct iio_dev_opaque' object).

Since a lot of drivers also call 'iio_priv()', in order to preserve
fast-paths (where this matters), the public iio_dev object will have a
'priv' field that will have the pointer to the private information already
computed. The reference returned by this field should be guaranteed to be
cacheline aligned.

The opaque parts will be moved into the 'include/linux/iio/iio-opaque.h'
header. Should the hidden information be required for some debugging or
some special needs, it can be made available via this header.
Otherwise, only the IIO core files should include this file.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper

We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.

For this driver, not using iio_priv_to_dev(), means reworking some paths to
pass the iio device and using iio_priv() to access the private information,
and also keeping a reference to the iio device for some quirky paths.

One [quirky] path is the at91_adc_workq_handler() which requires the IIO
device & the state struct to push to buffers.
Since this requires the back-ref to the IIO device, the
at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The
information required in this function is mostly for debugging purposes.
Replacing it with a reference to the IIO device would have been a slightly
bigger change, which may not be worth it (for just the debugging purpose
and given that we need the back-ref to the IIO device anyway).

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: scd30: add device binding file

Add SCD30 sensor binding file.

Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: chemical: scd30: add serial interface driver

Add serial interface driver for the SCD30 sensor.

Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: chemical: scd30: add I2C interface driver

Add I2C interface driver for the SCD30 sensor.

Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: chemical: scd30: add core driver

Add Sensirion SCD30 carbon dioxide core driver.

Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

MAINTAINERS: add entry for inv_icm42600 6-axis imu sensor

Add MAINTAINERS entry for InvenSense ICM-426xx IMU device.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: imu: Add inv_icm42600 documentation

Document the ICM-426xxx devices devicetree bindings.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add accurate timestamping

Add a timestamping mechanism for buffer that provides accurate
event timestamps when using watermark. This mechanism estimates
device internal clock by comparing FIFO interrupts delta time and
device elapsed time computed by parsing FIFO data.

Take interrupt timestamp in hard irq handler and add IIO device
specific timestamp structures in device private allocation.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add buffer support in iio devices

Add all FIFO parsing and reading functions. Add accel and gyro
kfifo buffer and FIFO data parsing. Use device interrupt for
reading data FIFO and launching accel and gyro parsing.

Support hwfifo watermark by multiplexing gyro and accel settings.
Support hwfifo flush.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add device interrupt

Add INT1 interrupt support. Support interrupt edge and level,
active high or low. Push-pull or open-drain configurations.

Interrupt will be used to read data from the FIFO.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation: ABI: add specific icm42600 documentation

Hardware offset available as calibscale sysfs attributes are real
physical values exprimed in SI units.

calibscale_available sysfs attributes represents the range of
acceptable values.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: add Kconfig and Makefile for inv_icm42600 driver

Add 3 modules: inv-icm42600, inv-icm42600-i2c, inv-icm42600-spi.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add temperature sensor support

Add temperature channel in gyroscope and accelerometer devices.

Temperature is available in full 16 bits resolution when reading
register and in low 8 bits resolution in the FIFO. Return full
precision raw temperature with corresponding scale and offset.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add accelerometer IIO device

Add IIO device for accelerometer sensor with data polling
interface.
Attributes: raw, scale, sampling_frequency, calibbias.

Accelerometer in low noise mode.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add gyroscope IIO device

Add IIO device for gyroscope sensor with data polling interface.
Attributes: raw, scale, sampling_frequency, calibbias.

Gyroscope in low noise mode.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add SPI driver for inv_icm42600 driver

Add SPI driver for InvenSense ICM-426xxx devices.

Configure bus signal slew rates as indicated in the datasheet.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add I2C driver for inv_icm42600 driver

Add I2C driver for InvenSense ICM-426xxx devices.

Configure bus signal slew rates as indicated in the datasheet.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_icm42600: add core of new inv_icm42600 driver

Core component of a new driver for InvenSense ICM-426xx devices.
It includes registers definition, main probe/setup, and device
utility functions.

ICM-426xx devices are latest generation of 6-axis IMU,
gyroscope+accelerometer and temperature sensor. This device
includes a 2K FIFO, supports I2C/I3C/SPI, and provides
intelligent motion features like pedometer, tilt detection,
and tap detection.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Combine read functions for PMIC5 and PMIC7

Add a common function used for read_raw callback for both PMIC5
and PMIC7 ADCs.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: rockchip_saradc: Add support iio buffers

Add the ability to also support access via (triggered) buffers
next to the existing direct mode.

Device in question is the Odroid Go Advance that connects a joystick
to two of the saradc channels for X and Y axis and the new (and still
pending) adc joystick driver of course wants to use triggered buffers
from the iio subsystem.

Signed-off-by: Simon Xue <xxm@rock-chips.com>
[some simplifications and added commit description]
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: rockchip_saradc: better prefix for channel constant

As suggested give the current ADC_CHANNEL constant a distinct
and consistent prefix.

Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: rockchip_saradc: move all of probe to devm-functions

Parts of the saradc probe rely on devm functions and later parts do not.
This makes it more difficult to for example enable triggers via their
devm-functions and would need more undo-work in remove.

So to make life easier for the driver, move the rest of probe calls
also to their devm-equivalents.

This includes moving the clk- and regulator-disabling to a devm_action
so that they gets disabled both during remove and in the error case
in probe, after the action is registered.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: Move attach/detach of the poll func to the core

All devices using a triggered buffer need to attach and detach the trigger
to the device in order to properly work. Instead of doing this in each and
every driver by hand move this into the core.

At this point in time, all drivers should have been resolved to
attach/detach the poll-function in the same order.

This patch removes all explicit calls of iio_triggered_buffer_postenable()
& iio_triggered_buffer_predisable() in all drivers, since the core handles
now the pollfunc attach/detach.

The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
not immediately obvious that removing the hooks doesn't break anything.
Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board.
All seems to be fine.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Tested-by: Eugen Hristev <eugen.hristev@microchip.com> #for at91-sama5d2-adc
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: at91_adc: remove usage of iio_priv_to_dev() helper

We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.

For this driver, not using iio_priv_to_dev(), means reworking some paths to
pass the iio device and using iio_priv() to access the private information.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Tested-by: Eugen Hristev <eugen.hristev@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: stm32-dfsdm-adc: remove usage of iio_priv_to_dev() helper

We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.

For this driver, not using iio_priv_to_dev(), means reworking some paths to
pass the iio device and using iio_priv() to access the private information.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: cros_ec: fix spelling mistake

Fix typo: "tigger" --> "trigger"

Signed-off-by: Keyur Patel <iamkeyur96@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: Remove superfluous of_node assignments

If a driver does not assign an of_node to a IIO device to IIO core will
automatically assign the of_node of the parent device. This automatic
assignment is done in the iio_device_register() function.

There is a fair amount of drivers that currently manually assign the
of_node of the IIO device. All but 4 of them can make use of the automatic
assignment though.

The exceptions are:
 * mxs-lradc-adc: Which uses the of_node of the parent of the parent.
 * stm32-dfsdm-adc, stm32-adc and stm32-dac: Which reference the of_node
   assigned to the IIO device before iio_device_register() is called.

All other drivers are updated to use automatic assignment. This reduces
the amount of boilerplate code involved in setting up the IIO device.

The patch has mostly been auto-generated with the following semantic patch

// <smpl>
@exists@
expression indio_dev;
expression parent;
@@
indio_dev = \(devm_iio_device_alloc\|iio_device_alloc\)(&parent, ...)
...
-indio_dev->dev.of_node = parent.of_node;

@exists@
expression indio_dev;
expression parent;
@@
indio_dev = \(devm_iio_device_alloc\|iio_device_alloc\)(parent, ...)
...
-indio_dev->dev.of_node = parent->of_node;
// </smpl>

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: remove left-over parent assignments

These were found by doing some shell magic:
------------
for file in $(git grep -w devm_iio_device_alloc | cut -d: -f1 | sort | uniq) ; do
if grep 'parent =' $file | grep -v trig | grep -vq devm_; then
echo "$file -> $(grep "parent =" $file)"
fi
done
-----------

The output is bearable [after the semantic patch is applied].
There is a mix of trigger assignments with some iio device parent
assignments that are removed via this patch.

JC: A few more added via inspection of all parent =
statements in drivers/iio. Some of these may just have crossed with this
series, others were less obvious to scripting due to some cross
file / module boundary calls.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: lm3533-als: use iio_device_set_parent() to assign parent

This assignment is the more peculiar as it assigns the parent of the
platform-device's device (i.e. pdev->dev.parent) as the IIO device's
parent.

Since the devm_iio_device_alloc() [now] assigns the device argument as the
default parent (and since this is the more common case), for cases
where the parent needs to be different, the iio_device_set_parent helper
should be used.

That makes things a bit more obvious about the new behavior of
devm_iio_device_alloc() and makes it clearer that iio_device_set_parent()
should be used.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: remove left-over comments about parent assignment

These were obtained by doing a 'git diff | grep \/\*', in the previous diff
to find comments. These needed a bit more manual review, as the semantic
patch isn't great for catching these.

The result is:
  /* Initialize Counter device and driver data */
  /* Initialize IIO device */
  /* Establish that the iio_dev is a child of the spi device */
  /* Estabilish that the iio_dev is a child of the spi device */
  /* Initiate the Industrial I/O device */
  /* Establish that the iio_dev is a child of the device */
- /* establish that the iio_dev is a child of the i2c device */
- /* establish that the iio_dev is a child of the i2c device */
  /* This is only used for removal purposes */
  /* setup the industrialio driver allocated elements */
  /* variant specific configuration */
  /* Setup for userspace synchronous on demand sampling. */
  st->readback_delay_us += 5; /* Add tWAIT */
- /* Establish that the iio_dev is a child of the i2c device */
  /* Establish that the iio_dev is a child of the i2c device */

Out of which, 4 are really left-over comments about parent assignment.
3 of them are removed by the semantic patch, as the comment removed (by
spatch) would be for an empty line.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: remove explicit IIO device parent assignment

This patch applies the semantic patch:
@@
expression I, P, SP;
@@
   I = devm_iio_device_alloc(P, SP);
   ...
-  I->dev.parent = P;

It updates 302 files and does 307 deletions.
This semantic patch also removes some comments like
'/* Establish that the iio_dev is a child of the i2c device */'

But this is is only done in case where the block is left empty.

The patch does not seem to cover all cases. It looks like in some cases a
different variable is used in some cases to assign the parent, but it
points to the same reference.
In other cases, the block covered by ... may be just too big to be covered
by the semantic patch.

However, this looks pretty good as well, as it does cover a big bulk of the
drivers that should remove the parent assignment.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: add iio_device_set_parent() helper

By default, the device allocation will also assign a parent device to the
IIO device object. In cases where devm_iio_device_alloc() is used,
sometimes the parent device must be different than the device used to
manage the allocation.

In that case, this helper should be used to change the parent, hence the
requirement to call this between allocation & registration.

This pattern/requirement is not very common in the IIO space, and it may be
cleaned up later.
But until then, assigning the parent manually between allocation &
registration is slightly easier.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: pass parent device as parameter during allocation

The change passes the parent device to the iio_device_alloc() call. This
also updates the devm_iio_device_alloc() call to consider the device object
as the parent device by default.

Having it passed like this, should ensure that any IIO device object
already has a device object as parent, allowing for neater control, like
passing the 'indio_dev' object for other stuff [like buffers/triggers/etc],
and potentially creating iiom_xxx(indio_dev) functions.

With this patch, only the 'drivers/platform/x86/toshiba_acpi.c' needs an
update to pass the parent object as a parameter.

In the next patch all devm_iio_device_alloc() calls will be handled.

Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: amplifiers: ad8366: Change devm_gpiod_get() to optional and add the missed check

Since if there is no GPIO, nothing happens, replace devm_gpiod_get()
with devm_gpiod_get_optional().
Also add IS_ERR() to fix the missing-check warning.

Fixes: cee211f4e5a0 ("iio: amplifiers: ad8366: Add support for the ADA4961 DGA")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: improve IIO_CONCENTRATION channel type description

IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting
raw concentrations of pollutants. Raw value should be meaningless
before being properly scaled. Because of that description shouldn't
mention raw value unit whatsoever.

Fix this by rephrasing existing description so it follows conventions
used throughout IIO ABI docs.

Fixes: 8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type")
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver

Since changes can come from all sort of places, it may make sense to have
this symbol as a dependency to make sure that the 'make allmodconfig' &&
'make allyesconfig' build rules cover this driver as well for a
compile-build/test.

It seemed useful [recently] when trying to apply a change for this.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: make iio_device_get_drvdata take a const struct iio_dev *.

As this just calls dev_get_drvdata underneath which is happy with
a const struct device * we should change and avoid potentially
casting away a const in order to then put it back again.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: stm32-adc: remove usage of iio_priv_to_dev() helper

We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.

For this driver, not using iio_priv_to_dev(), means reworking some paths to
pass the iio device and using iio_priv() to access the private information.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad5592r: remove usage of iio_priv_to_dev() helper

This was partially removed when the mlock cleanup was done. Only one more
call is left in the ad5592r_alloc_channels() function.
This one is simple. We just need to pass the iio_dev object and get the
state via iio_priv().

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: bmi160: added mount-matrix support

Add mount-matrix binding support. As chip could have different orientations
a mount matrix support is needed to correctly translate these differences.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: bmi160: added regulator support

Add vdd-supply and vddio-supply support.

While working on an msm8916 device and having explicit declarations for
regulators, without setting these regulators to regulators-always-on it
happened those lines weren't ready because they could have been controlled
by other components, causing failure in module's probe.

This patch aim is to solve this situation by adding regulators control
during bmi160_chip_init() and bmi160_chip_uninit(), assuring power to
this component.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: bmi160: fix typo

Fix a typo in MODULE_AUTHOR() argument.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: imu: bmi160: add regulators and mount-matrix

Add vdd-supply and vddio-supply support.
Add mount-matrix support.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: cros_ec: Reapply range at resume

EC does not currently preserve range across sensor reinit.
If sensor is powered down at suspend, it will default to the EC default
range at resume, not the range set by the host.

Save range if modified, and apply at resume.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: mxc4005: add support for mxc6655

The mxc6655 is fully working with the existing mxc4005 driver.
Add support for it.

Signed-off-by: Christian Oder <me@myself5.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: magnetometer: mmc35240: Constify struct reg_default

mmc35240_reg_defaults is not modified and can be made const to allow the
compiler to put it in read-only memory.

Before:
   text    data     bss     dec     hex filename
   9759    3288     128   13175    3377 drivers/iio/magnetometer/mmc35240.o

After:
   text    data     bss     dec     hex filename
   9823    3224     128   13175    3377 drivers/iio/magnetometer/mmc35240.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: stk3310: Constify regmap_config

stk3310_regmap_config is not modified and can be made const to allow the
compiler to put it in read-only memory.

Before:
   text    data     bss     dec     hex filename
  16027    5424     128   21579    544b drivers/iio/light/stk3310.o

After:
   text    data     bss     dec     hex filename
  16347    5104     128   21579    544b drivers/iio/light/stk3310.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad5592r-base: Constify struct iio_chan_spec_ext_info

ad5592r_ext_info is not modified and can be made const to allow the
compiler to put it in read-only memory.

Before:
   text    data     bss     dec     hex filename
  13293    2088     256   15637    3d15 drivers/iio/dac/ad5592r-base.o

After:
   text    data     bss     dec     hex filename
  13421    1960     256   15637    3d15 drivers/iio/dac/ad5592r-base.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad5380: Constify struct iio_chan_spec_ext_info

ad5380_ext_info is not modified and can be made const to allow the
compiler to put it in read-only memory.

Before:
   text    data     bss     dec     hex filename
  12060    3280     192   15532    3cac drivers/iio/dac/ad5380.o

After:
   text    data     bss     dec     hex filename
  12252    3088     192   15532    3cac drivers/iio/dac/ad5380.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: max11100: Constify struct iio_chan_spec

max11100_channels is not modified and can therefore be made const to
allow the compiler to put it in read-only memory.

Before:
   text    data     bss     dec     hex filename
   3776    1168       0    4944    1350 drivers/iio/adc/max11100.o

After:
   text    data     bss     dec     hex filename
   3968     976       0    4944    1350 drivers/iio/adc/max11100.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_mpu6050: Drop double check for ACPI companion device

acpi_dev_get_resources() does perform the NULL pointer check against
ACPI companion device which is given as function parameter. Thus,
there is no need to duplicate this check in the caller.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: magnetometer: ak8975: Add gpio reset support

According to AK09911 datasheet, if reset gpio is provided then
deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().

Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.

AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: magnetometer: ak8975: Fix typo, uniform measurement unit style

Minor comment style edits.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: magnetometer: ak8975: add gpio reset support

Add reset-gpio support.

Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.

AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer

Converts documentation from txt format to yaml.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: magnetometer: ak8975: reword gpios, add interrupts, fix style

Reword gpios documentation, add interrupt documentation and fix styles.
Update example to use interrupts instead of gpios.

Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Update debug prints

Change pr_err/pr_debug statements to dev_err/dev_dbg for
increased clarity.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Update return value checks

Clean up some return value checks to make code more compact.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Add support for PMIC7 ADC

The ADC architecture on PMIC7 is changed as compared to PMIC5. The
major change from PMIC5 is that all SW communication to ADC goes through
PMK8350, which communicates with other PMICs through PBS when the ADC
on PMK8350 works in master mode. The SID register is used to identify the
PMICs with which the PBS needs to communicate. Add support for the same.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Add info property under adc_data

Add info property under adc_data to support adding ADC variants
which may use different iio_info than the one defined for PMIC5.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Add PMIC7 ADC bindings

Add documentation for PMIC7 ADC peripheral.
For the PMIC7-type PMICs, ADC peripheral is present in HW for the
following PMICs: PMK8350, PM8350, PM8350b, PMR735a and PMR735b.
Of these, only the ADC peripheral on PMK8350 is exposed directly to SW.
If SW needs to communicate with ADCs on other PMICs, it specifies the
PMIC to PMK8350 through the newly added SID register and communication
between PMK8350 ADC and other PMIC ADCs is carried out through
PBS(Programmable Boot Sequence) at the firmware level.

In addition, add definitions for ADC channels and virtual channel
definitions (combination of ADC channel number and PMIC SID number)
per PMIC, to be used by ADC clients for PMIC7.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Convert the QCOM SPMI ADC bindings to .yaml format

Convert the adc bindings from .txt to .yaml format.

Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: bma400: add support for bma400 spi

Add basic support for the Bosch Sensortec BMA400 3-axes ultra-low power
accelerometer when configured to use SPI.

Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: chemical: atlas-ezo-sensor: move ret variable scope in atlas_ezo_read_raw()

Move ret variable to the IIO_CHAN_INFO_RAW switch since currently
only used within that scope.

Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: humidity: hts221: remove usage of iio_priv_to_dev()

We may want to get rid of the iio_priv_to_dev() helper. That's a bit
uncertain at this point. The reason is that we will hide some of the
members of the iio_dev structure (to prevent drivers from accessing them
directly), and that will also mean hiding the implementation of the
iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.

For this driver, removing the iio_priv_to_dev() helper means passing the
iio_dev object on hts221_allocate_buffers() & hts221_allocate_trigger().

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: position: iqs624: remove usage of iio_priv_to_dev()

We may want to get rid of the iio_priv_to_dev() helper. That's a bit
uncertain at this point. The reason is that we will hide some of the
members of the iio_dev structure (to prevent drivers from accessing them
directly), and that will also mean hiding the implementation of the
iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.

For this driver, removing iio_priv_to_dev() also means keeping a reference
on the state struct.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: iqs621: remove usage of iio_priv_to_dev()

We may want to get rid of the iio_priv_to_dev() helper. That's a bit
uncertain at this point. The reason is that we will hide some of the
members of the iio_dev structure (to prevent drivers from accessing them
directly), and that will also mean hiding the implementation of the
iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.

For this driver, removing iio_priv_to_dev() means keeping a reference
on the state struct.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: tsl2563: pass iio device as i2c_client private data

We may want to get rid of the iio_priv_to_dev() helper. That's a bit
uncertain at this point. The reason is that we will hide some of the
members of the iio_dev structure (to prevent drivers from accessing them
directly), and that will also mean hiding the implementation of the
iio_priv_to_dev() helper inside the IIO core.

Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.

For this driver, it implies passing the IIO device on the i2c client
private data. The implementation of iio_priv() will not be affected by the
rework/hiding of iio_priv_to_dev().

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Merge tag 'locking-kcsan-2020-06-11' of git://git./linux/kernel/git/tip/tip

Pull the Kernel Concurrency Sanitizer from Thomas Gleixner:
 "The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector,
  which relies on compile-time instrumentation, and uses a
  watchpoint-based sampling approach to detect races.

  The feature was under development for quite some time and has already
  found legitimate bugs.

  Unfortunately it comes with a limitation, which was only understood
  late in the development cycle:

     It requires an up to date CLANG-11 compiler

  CLANG-11 is not yet released (scheduled for June), but it's the only
  compiler today which handles the kernel requirements and especially
  the annotations of functions to exclude them from KCSAN
  instrumentation correctly.

  These annotations really need to work so that low level entry code and
  especially int3 text poke handling can be completely isolated.

  A detailed discussion of the requirements and compiler issues can be
  found here:

    https://lore.kernel.org/lkml/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com/

  We came to the conclusion that trying to work around compiler
  limitations and bugs again would end up in a major trainwreck, so
  requiring a working compiler seemed to be the best choice.

  For Continous Integration purposes the compiler restriction is
  manageable and that's where most xxSAN reports come from.

  For a change this limitation might make GCC people actually look at
  their bugs. Some issues with CSAN in GCC are 7 years old and one has
  been 'fixed' 3 years ago with a half baken solution which 'solved' the
  reported issue but not the underlying problem.

  The KCSAN developers also ponder to use a GCC plugin to become
  independent, but that's not something which will show up in a few
  days.

  Blocking KCSAN until wide spread compiler support is available is not
  a really good alternative because the continuous growth of lockless
  optimizations in the kernel demands proper tooling support"

* tag 'locking-kcsan-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (76 commits)
  compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining
  compiler.h: Move function attributes to compiler_types.h
  compiler.h: Avoid nested statement expression in data_race()
  compiler.h: Remove data_race() and unnecessary checks from {READ,WRITE}_ONCE()
  kcsan: Update Documentation to change supported compilers
  kcsan: Remove 'noinline' from __no_kcsan_or_inline
  kcsan: Pass option tsan-instrument-read-before-write to Clang
  kcsan: Support distinguishing volatile accesses
  kcsan: Restrict supported compilers
  kcsan: Avoid inserting __tsan_func_entry/exit if possible
  ubsan, kcsan: Don't combine sanitizer with kcov on clang
  objtool, kcsan: Add kcsan_disable_current() and kcsan_enable_current_nowarn()
  kcsan: Add __kcsan_{enable,disable}_current() variants
  checkpatch: Warn about data_race() without comment
  kcsan: Use GFP_ATOMIC under spin lock
  Improve KCSAN documentation a bit
  kcsan: Make reporting aware of KCSAN tests
  kcsan: Fix function matching in report
  kcsan: Change data_race() to no longer require marking racing accesses
  kcsan: Move kcsan_{disable,enable}_current() to kcsan-checks.h
  ...

Merge tag 'locking-urgent-2020-06-11' of git://git./linux/kernel/git/tip/tip

Pull atomics rework from Thomas Gleixner:
 "Peter Zijlstras rework of atomics and fallbacks. This solves two
  problems:

   1) Compilers uninline small atomic_* static inline functions which
      can expose them to instrumentation.

   2) The instrumentation of atomic primitives was done at the
      architecture level while composites or fallbacks were provided at
      the generic level. As a result there are no uninstrumented
      variants of the fallbacks.

  Both issues were in the way of fully isolating fragile entry code
  pathes and especially the text poke int3 handler which is prone to an
  endless recursion problem when anything in that code path is about to
  be instrumented. This was always a problem, but got elevated due to
  the new batch mode updates of tracing.

  The solution is to mark the functions __always_inline and to flip the
  fallback and instrumentation so the non-instrumented variants are at
  the architecture level and the instrumentation is done in generic
  code.

  The latter introduces another fallback variant which will go away once
  all architectures have been moved over to arch_atomic_*"

* tag 'locking-urgent-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/atomics: Flip fallbacks and instrumentation
  asm-generic/atomic: Use __always_inline for fallback wrappers