iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops.

If CONFIG_PM not set then clang warns this structure is unused.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-12-jic23@kernel.org

iio:dummy: Drop set but unused variable len.

Not sure what the thinking was here, as lost to history, but the
variable is clearly not used so get rid of it.

Warning seen with clang W=1 tests (may be present with other compilers
and build options).

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-11-jic23@kernel.org

iio:magn:ak8975: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-10-jic23@kernel.org

iio:imu:inv_mpu6050: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Baptiste Mansuy <bmansuy@invensense.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-9-jic23@kernel.org

iio:imu:inv_icm42600: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-8-jic23@kernel.org

iio:dac:mcp4725: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-7-jic23@kernel.org

iio:amplifiers:hmc425a: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-6-jic23@kernel.org

iio:adc:ti-ads1015: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-5-jic23@kernel.org

iio:adc:rcar: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-4-jic23@kernel.org

iio:adc:ina2xx-adc: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-3-jic23@kernel.org

iio:accel:bma180: Suppress clang W=1 warning about pointer to enum conversion.

Cast to a uintptr_t rather than directly to the enum.

As per the discussion in below linked media patch.

Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-2-jic23@kernel.org

drivers:iio:dac: Add AD3552R driver support

The AD3552R-16 is a low drift ultrafast, 16-bit accuracy,
current output digital-to-analog converter (DAC) designed
to generate multiple output voltage span ranges.
The AD3552R-16 operates with a fixed 2.5V reference.

Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf

Signed-off-by: Mihail Chindris <mihail.chindris@analog.com>
Link: https://lore.kernel.org/r/20211213110825.244347-3-mihail.chindris@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: dac: Add adi,ad3552r.yaml

Add documentation for ad3552r and ad3542r

Signed-off-by: Mihail Chindris <mihail.chindris@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:filter:admv8818: Add sysfs ABI documentation

Add initial ABI documentation for admv8818 filter sysfs interfaces.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings:iio:filter: add admv8818 doc

Add device tree bindings for the ADMV8818 Filter.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:filter:admv8818: add support for ADMV8818

The ADMV8818-EP is a fully monolithic microwave integrated
circuit (MMIC) that features a digitally selectable frequency of
operation. The device features four independently controlled high-
pass filters (HPFs) and four independently controlled low-pass
filters (LPFs) that span the 2 GHz to 18 GHz frequency range.

Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/admv8818-ep.pdf

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: add filter subfolder

Add filter subfolder for IIO devices that handle filter functionality.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: vz89x: Remove unnecessary cast

The case to u8 * is unnecessary here since the expression is already of
type u8 *.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: in2xx-adc: Remove unnecessary cast

`buf` is cast to a const char *, but `buf` is already a const char *, so
the case is unnecessary.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: as3935: Remove unnecessary cast

`buf` is cast to a const char *, but `buf` is already a const char *, so
the case is unnecessary.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: stmpe-adc: Use correctly sized arguments for bit field

The find.h APIs are designed to be used only on unsigned long arguments.
This can technically result in a over-read, but it is harmless in this
case. Regardless, fix it to avoid the warning seen under -Warray-bounds,
which we'd like to enable globally:

In file included from ./include/linux/bitmap.h:9,
                 from ./include/linux/cpumask.h:12,
                 from ./arch/x86/include/asm/cpumask.h:5,
                 from ./arch/x86/include/asm/msr.h:11,
                 from ./arch/x86/include/asm/processor.h:22,
                 from ./arch/x86/include/asm/cpufeature.h:5,
                 from ./arch/x86/include/asm/thread_info.h:53,
                 from ./include/linux/thread_info.h:60,
                 from ./arch/x86/include/asm/preempt.h:7,
                 from ./include/linux/preempt.h:78,
                 from ./include/linux/spinlock.h:55,
                 from ./include/linux/swait.h:7,
                 from ./include/linux/completion.h:12,
                 from drivers/iio/adc/stmpe-adc.c:10:
drivers/iio/adc/stmpe-adc.c: In function 'stmpe_adc_probe':
./include/linux/find.h:98:23: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Warray-bounds]
   98 |                 val = *addr | ~GENMASK(size - 1, offset);
      |                       ^~~~~
drivers/iio/adc/stmpe-adc.c:258:13: note: while referencing 'norequest_mask'
  258 |         u32 norequest_mask = 0;
      |             ^~~~~~~~~~~~~~

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:adc:ti-ads8688:: remove redundant ret variable

Return value from ads8688_prog_write() directly instead
of taking this in another redundant variable.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: fix off by one in ad74413r_parse_channel_config()

The > needs to be >= to prevent accessing one element beyond the end of
the st->channel_configs[] array.

Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7606: Fix syntax errors in comments

Delete the redundant word 'the'.

Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: event_monitor: Flush output on event

By flushing the output, iio_event_monitor can be more useful to programs
chained along with it.

  iio_event_monitor stk3310 | awk '/rising/{system("my_unlockscreen.sh")} /falling/{system("my_lockscreen.sh")}'

Without this flush, the above example would buffer a number of events,
then after a while run the lock/unlock scripts several times.

Signed-off-by: Zach DeCook <zachdecook@librem.one>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: iio_device_alloc(): Remove unnecessary self drvdata

Drvdata is typically used by drivers to attach driver specific data to a
device. It is used to retrieve driver specific information when only the
device to which the data is attached is available.

In the IIO core in the `iio_device_alloc()` function we call
`iio_device_set_drvdata(indio_dev, indio_dev)`. This sets the drvdata of
the IIO device to itself.

This is rather unnecessary since if we have a pointer to the IIO device to
call `iio_device_get_drvdata()` on it we don't need to call the function
since we already have the pointer. If we only have a pointer to the `struct
device` we can use `dev_to_iio_dev()` to get the IIO device from it.

Furthermore the drvdata is supposed to be reserved for drivers, so it
should not be used by the IIO core in the first place.

The `set_drvdata()` has been around from the very beginning of the IIO
framework and back then it was used in the IIO device sysfs attribute
handling code. But that was subsequently replaced with a `dev_to_iio_dev()`
in commit e53f5ac52ec1 ("iio: Use dev_to_iio_dev()") and other cleanups.

The self `set_drvdata()` is now no longer needed and can be removed.

Verified that there no longer any users by checking for potential users
using the following two coccinelle scripts and reviewing that none of the
matches are problematic code.

<smpl>
@@
struct iio_dev *iio_dev;
expression dev;
identifier fn !~ "(remove|resume|suspend)";
@@
fn(...)
{
...
*iio_dev = dev_get_drvdata(dev)
...
}
</smpl>

<smpl>
@r1@
position p;
struct iio_dev *indio_dev;
identifier dev_fn =~ "^dev_";
identifier devm_fn =~ "^devm_";
@@
(
 dev_fn
|
 devm_fn
)
 (&indio_dev@p->dev, ...)

@@
struct iio_dev *indio_dev;
position p != r1.p;
@@
*&indio_dev@p->dev</smpl>

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: dac: adi,ad5755: drop unrelated included.

Probably a cut and paste error, but the binding header used in the
example is for the wrong device and nothing from it is used.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Reviewed-by: Rob Herring <robh@kernel.org>

iio:adc/dac:Kconfig: Update to drop OF dependencies.

We could probably drop a lot more of these, but for now this removes
unnecessary restrictions on stand alone ADC devices.

For these 3 drivers the false dependency seems to date all
the way back to their initial introduction.

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

iio:adc:ti-ads124s08: Drop dependency on OF.

Nothing in this driver depends on OF firmware so drop the dependency
and update the headers to remove the false impression such a dependency
exists.

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

iio:adc:envelope-detector: Switch from of headers to mod_devicetable.h

There is nothing directly using of specific interfaces in this driver,
so lets not include the headers.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:adc:ti-adc12138: Switch to generic firmware properties and drop of_match_ptr

This enables using the driver with other firmware types such
as ACPI via PRP0001.

Also part of a general attempt to move IIO drivers over to generic
properties to avoid opportunities for cut and paste.

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

iio:adc:mcp3911: Switch to generic firmware properties.

This allows use of the driver with other types of firmware such as ACPI
PRP0001 based probing.

Also part of a general attempt to remove direct use of of_ specific
accessors from IIO.

Added an include for mod_devicetable.h whilst here to cover the
struct of_device_id definition.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Kent Gustavsson <kent@minoris.se>
Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com>

iio:adc:max9611: Switch to generic firmware properties.

Note the handling of the device tree node in this driver was somewhat
unusual.  I have cleaned that up whilst also moving over to generic
properties.

Part of a general attempt to move all IIO drivers over to generic
firmware properties both as a general improvement and to avoid sources
of cut and paste into future drivers.

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

iio:light:cm3605: Switch to generic firmware properties.

This enables use of other firmware types with minimal driver changes.
Part of an ongoing effort to move all IIO drivers over to generic
accessors in order to reduce the chance of of_* versions being
copied into new drivers.  Also updated the headers to reflect this change
including using mod_devicetable.h for struct of_device_id definition
rather than going via of.h

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

iio:pot:mcp41010: Switch to generic firmware properties.

In this case it was only of_device_get_match_data() + header update.
This enables use of other firmware types with no other changes, such
as ACPI via the PRP0001 route.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Chris Coffey <cmc@babblebit.net>

iio:dac:lpc18xx_dac: Swap from of* to mod_devicetable.h

This driver never used anything from the of specific headers.
mod_devicetable.h provides the struct of_device_id definition.

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

iio:dac:dpot-dac: Swap of.h for mod_devicetable.h

This driver never used anything in the of specific header.
It just wants the struct of_device_id from mod_devicetable.h.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Peter Rosin <peda@axentia.se>

iio:dac:ad5758: Drop unused of specific headers.

These have never been used in this driver.  What is used is in
mod_devicetable.h so add that include (struct of_device_id)

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

iio:dac:ad5755: Switch to generic firmware properties and drop pdata

Lars pointed out that platform data can also be supported via the
generic properties interface, so there is no point in continuing to
support it separately.  Hence squish the linux/platform_data/ad5755.h
header into the c file and drop accessing the platform data directly.

Done by inspection only.  Mostly completely mechanical with the
exception of a few places where default value handling is
cleaner done by first setting the value, then calling the
firmware reading function but and not checking the return value,
as opposed to reading firmware then setting the default if an error
occurs.

Part of general attempt to move all of IIO over to generic
device properties, both to enable other firmware types and
to remove drivers that can be the source of of_ specific
behaviour in new drivers.

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

iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046

IIO triggers are software IRQ chips that split an incoming IRQ into
separate IRQs routed to all devices using the trigger.
When all consumers are done then a trigger callback reenable() is
called.  There are a few circumstances under which this can happen
in atomic context.

1) A single user of the trigger that calls the iio_trigger_done()
function from interrupt context.
2) A race between disconnecting the last device from a trigger and
the trigger itself sucessfully being disabled.

To avoid a resulting scheduling whilst atomic, close this second corner
by using schedule_work() to ensure the reenable is not done in atomic
context.

Note that drivers must be careful to manage the interaction of
set_state() and reenable() callbacks to ensure appropriate reference
counting if they are relying on the same hardware controls.

Deliberately taking this the slow path rather than via a fixes tree
because the error has hard to hit and I would like it to soak for a while
before hitting a release kernel.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211017172209.112387-1-jic23@kernel.org

iio: addac: add AD74413R driver

The AD74412R and AD74413R are quad-channel, software configurable,
input/output solutions for building and process control applications.

They contain functionality for analog output, analog input, digital input,
resistance temperature detector, and thermocouple measurements integrated
into a single chip solution with an SPI interface.

The devices feature a 16-bit ADC and four configurable 13-bit DACs to
provide four configurable input/output channels and a suite of diagnostic
functions.

The AD74413R differentiates itself from the AD74412R by being
HART-compatible.

When configured with channel 0 as voltage output, channel 1 as current
output, channel 2 as voltage input and channel 3 as current input, the
following structure is created under the corresponding IIO device.

.
├── in_current0_offset
├── in_current0_raw
├── in_current0_sampling_frequency
├── in_current0_sampling_frequency_available
├── in_current0_scale
├── in_voltage1_offset
├── in_voltage1_raw
├── in_voltage1_sampling_frequency
├── in_voltage1_sampling_frequency_available
├── in_voltage1_scale
├── in_voltage2_offset
├── in_voltage2_raw
├── in_voltage2_sampling_frequency
├── in_voltage2_sampling_frequency_available
├── in_voltage2_scale
├── in_current3_offset
├── in_current3_raw
├── in_current3_sampling_frequency
├── in_current3_sampling_frequency_available
├── in_current3_scale
├── out_voltage0_raw
├── out_voltage0_scale
├── out_current1_raw
├── out_current1_scale
├── name
├── buffer
│   ├── data_available
│   ├── enable
│   ├── length
│   └── watermark
└── scan_elements
    ├── in_current0_en
    ├── in_current0_index
    ├── in_current0_type
    ├── in_voltage1_en
    ├── in_voltage1_index
    ├── in_voltage1_type
    ├── in_voltage2_en
    ├── in_voltage2_index
    ├── in_voltage2_type
    ├── in_current3_en
    ├── in_current3_index
    └── in_current3_type

Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211205114045.173612-4-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: add AD74413R

The AD74412R and AD74413R are quad-channel, software configurable,
input/output solutions for building and process control applications.

They contain functionality for analog output, analog input, digital input,
resistance temperature detector, and thermocouple measurements integrated
into a single chip solution with an SPI interface.

The devices feature a 16-bit ADC and four configurable 13-bit DACs to
provide four configurable input/output channels and a suite of diagnostic
functions.

The AD74413R differentiates itself from the AD74412R by being
HART-compatible.

Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211205114045.173612-3-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: add addac subdirectory

For IIO devices that expose both ADC and DAC functionality.

Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20211205114045.173612-2-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

MAINTAINERS: Update i.MX 8QXP ADC info

Update my email address to use developer mail address,
because the old address will be dropped soon.

And change the status from 'Supported' to 'Maintained' for me
to look after this code without any payment now.

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20211201083100.1587-1-caihuoqing@baidu.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings:iio:dac: add ad7293 doc

Add device tree bindings for the AD7293 Power Amplifier.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211202150819.24832-2-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:dac:ad7293: add support for AD7293

The AD7293 is a Power Amplifier drain current controller
containing functionality for general-purpose monitoring
and control of current, voltage, and temperature, integrated
into a single chip solution with an SPI-compatible interface.

Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7293.pdf

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Cai Huoqing <cai.huoqing@linux.dev>
Link: https://lore.kernel.org/r/20211202150819.24832-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ltr501: Export near level property for proximity sensor

Userspace tools like iio-sensor-proxy need to know the proximity level
that should be considered "near". This value is hardware-specific and
can be defined via the devicetree. Allow the driver to export the near
level.

Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20211125125646.54831-2-nikita@trvn.ru
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: light: ltr501: Add proximity-near-level

This value inidcates the proximity level that should be considered
"close".

Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211125125646.54831-1-nikita@trvn.ru
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: adc: document TS voltage in AXP PMICs

Most AXPxxx-based reference designs place a 10k NTC thermistor on a
TS pin. axp20x IIO driver now report the voltage of this pin via
additional IIO channel. Add new "ts_v" channel to the channel description.

Signed-off-by: Evgeny Boger <boger@wirenboard.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Quentin Schulz <foss+kernel@0leil.net>
Link: https://lore.kernel.org/r/20211118141233.247907-3-boger@wirenboard.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:adc:axp20x: add support for NTC thermistor

Most AXPxxx-based reference designs place a 10k NTC thermistor on a
TS pin. When appropriately configured, AXP PMICs will inject fixed
current (80uA by default) into TS pin and measure the voltage across a
thermistor. The PMIC itself will by default compare this voltage with
predefined thresholds  and disable battery charging whenever
the battery is too hot or too cold.

Alternatively, the TS pin can be configured as general-purpose
ADC input. This mode is not supported by the driver.

This patch allows reading the voltage on the TS pin. It can be then
either processed by userspace or used by kernel consumer like hwmon
ntc thermistor driver.

Signed-off-by: Evgeny Boger <boger@wirenboard.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Quentin Schulz <foss+kernel@0leil.net>
Link: https://lore.kernel.org/r/20211118141233.247907-2-boger@wirenboard.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation: dt: iio: st_lsm6dsx: add disable-sensor-hub property

Enable/disable internal i2c controller slave autoprobing at bootstrap.
Disable sensor-hub is useful if i2c controller clock/data lines are
connected through a pull-up with other chip lines (e.g. SDO/SA0).

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/54287a93922ac839501b776d288cc368aa81f0ab.1636816719.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: add dts property to disable sensor-hub

Introduce the capability to disable sensorhub through a device-tree
property since there are some configurations where users want to
explicitly disable sensor-hub auto-probing at bootstrap.
A typical configuration is when the sensorhub clock/data lines are connected
to a pull-up resistor since no slave sensors are connected to the i2c master.
If SDO/SA0 line is connected to the same pull-up resistor, when the driver
tries to probe slave devices connected on sensor-hub, it will force SDO/SA0
line to low, modifying the device i2c address.

Tested-by: Mario Tesi <mario.tesi@st.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/ad7894e7b1c6fb3427fab3f623bb942860ad45cf.1636816719.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: test: Add test for IIO_VAL_INT_64.

Add test for newly introduced type IIO_VAL_INT_64.

Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20211105100501.1904-3-andriy.tryshnivskyy@opensynergy.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: test: Add check against NULL for buffer in tests.

Add KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf) for every test.
Also use ARRAY_SIZE(values) where it is possible.

Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20211105100501.1904-2-andriy.tryshnivskyy@opensynergy.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: expose shared parameter in IIO_ENUM_AVAILABLE

The shared parameter should be configurable based on its usage, and not
constrained to IIO_SHARED_BY_TYPE.

This patch aims to improve the flexibility in using the
IIO_ENUM_AVAILABLE define and avoid redefining custom iio enums that
expose the shared parameter.

An example is the ad5766.c driver where IIO_ENUM_AVAILABLE_SHARED was
defined in order to achieve `shared` parameter customization.

The current state of the IIO_ENUM_AVAILABLE implementation will imply
similar redefinitions each time a driver will require access to the
`shared` parameter. An example would be admv1013 driver which will
require custom device attribute for the frequency translation modes:
Quadrature I/Q mode and Intermediate Frequency mode.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211119085627.6348-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer-dma: Use round_down() instead of rounddown()

We know that the buffer's alignment will always be a power of two;
therefore, we can use the faster round_down() macro.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211115141925.60164-4-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer-dma: Remove unused iio_buffer_block struct

This structure was never used anywhere, so it can safely be dropped.

It will later be re-introduced as a different structure in a
different header.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211115141925.60164-3-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer: Use dedicated variable in iio_buffers_alloc_sysfs_and_mask()

Use dedicated variable for index in the loop in the
iio_buffers_alloc_sysfs_and_mask(). This will make code cleaner and
less error prone as proved by previous changes done in this function.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211013094923.2473-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: ltr501: Added ltr303 driver support

Previously ltr501 driver supported a number of light and,
proximity sensors including ltr501, ltr559 and ltr301.
This adds support for another light sensor ltr303
used in Seeed Studio reTerminal, a carrier board
for Raspberry Pi 4 CM.

Signed-off-by: Maslov Dmitry <maslovdmitry@seeed.cc>
Link: https://lore.kernel.org/r/20211106174137.6783-1-maslovdmitry@seeed.cc
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: rzg2l_adc: Remove unnecessary print function dev_err()

The print function dev_err() is redundant because
platform_get_irq() already prints an error.

Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20211105015504.39226-1-vulab@iscas.ac.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: mpl3115: Use scan_type.shift and realbit in mpl3115_read_raw

When processing raw data using channel scan_type.shift as source of
trust to shift data appropriately.
When processing the temperature channel, use a 16bit big endian variable
as buffer to increase conversion readability.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-14-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: xilinx-xadc-core: Use local variable in xadc_read_raw

Minor cleanup: bit is already defined as chan->scan_type.realbits,
use bit when needed.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-13-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ti-ads1015: Remove shift variable ads1015_read_raw

By using scan_type.realbits when processing raw data,
we use scan_type.shit only once, thus we don't need to define a local
variable for it anymore.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-12-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: mag3110: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-11-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ti-adc12138: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-10-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ad7266: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-8-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: stk8ba50: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-7-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: stk8312: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-6-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: sca3000: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-5-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: mma7455: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-4-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: kxcjk-1013: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: bma220: Use scan_type when processing raw data

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-2-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: at91-sama5d2: Use dev_to_iio_dev() in sysfs callbacks

Using `dev_get_drvdata()` in IIO sysfs callbacks to get a pointer to the
IIO device is a relic from the very early days of IIO. The IIO core as well
as most other drivers have switched over to using `dev_to_iio_dev()`
instead.

This driver is one of the last few drivers remaining that uses the outdated
idiom, update it. This will allow to eventually update the IIO core to no
longer set the drvdata for the IIO device and free it up for driver usage.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211019082929.30503-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: at91-sama5d2: Fix incorrect cast to platform_device

The at91-sama5d2 driver calls `to_platform_device()` on a struct device
that is part of a IIO device. This is incorrect since
`to_platform_device()` must only be called on a struct device that is part
of a platform device.

The code still works by accident because non of the struct platform_device
specific fields are accessed.

Refactor the code a bit so that it behaves identically, but does not use
the incorrect cast. This avoids accidentally adding undefined behavior in
the future by assuming the `struct platform_device` is actually valid.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Eugen Hristev <eugen.hristev@microchip.com>
Link: https://lore.kernel.org/r/20211019082929.30503-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: mma8452: Use correct type for return variable in IRQ handler

The IRQ handler's return type is irqreturn_t. The mma8452 uses a variable
to store the return value, but the variable is of type int. Change this to
irqreturn_t. This makes it easier to verify that the code is correct.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20211101102734.32291-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: lmp91000: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-9-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: gp2ap020a00f: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-8-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: atlas-sensor: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the same as if
the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-7-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: as3935: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-6-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: afe4404: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-5-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: afe4403: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-4-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ad_sigma_delta: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-3-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: sysfs-trigger: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: interrupt-trigger: Remove no-op trigger ops

The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.

Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: Mark iio_device_type as const

The iio_device_type struct is never modified, mark it as const. This allows
it to be placed in a read-only memory section, which will protect against
accidental or deliberate modification.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031080421.2086-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio/scmi: Add reading "raw" attribute.

Add IIO_CHAN_INFO_RAW to the mask and implement corresponding
reading "raw" attribute in scmi_iio_read_raw.

Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com>
Acked-by: Jyoti Bhayana <jbhayana@google.com>
Link: https://lore.kernel.org/r/20211024091627.28031-3-andriy.tryshnivskyy@opensynergy.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: Introduce IIO_VAL_INT_64.

Introduce IIO_VAL_INT_64 to read 64-bit value for
channel attribute. Val is used as lower 32 bits.

Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com>
Link: https://lore.kernel.org/r/20211024091627.28031-2-andriy.tryshnivskyy@opensynergy.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ina2xx: Avoid double reference counting from get_task_struct/put_task_struct()

kthread_run() and kthread_stop() already do reference
counting of the task, so remove get_task_struct/put_task_struct()
to avoid double reference counting.

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20211021124254.3247-2-caihuoqing@baidu.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ina2xx: Make use of the helper macro kthread_run()

Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.

Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20211021124254.3247-1-caihuoqing@baidu.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ms5611: Simplify IO callback parameters

The ms5611 passes &indio_dev->dev as a parameter to all its IO callbacks
only to directly cast the struct device back to struct iio_dev. And the
struct iio_dev is then only used to get the drivers state struct.

Simplify this a bit by passing the state struct directly. This makes it a
bit easier to follow what the code is doing.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211020142110.7060-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imx7d_adc: Don't pass IIO device to imx7d_adc_{enable,disable}()

The `imx7d_adc_enable()` and `imx7d_adc_disable()` functions are used as
the suspend and resume callbacks for the device. When called as
suspend/resume functions they are called with the platform_device's device
as their parameter.

In addition the functions are called on device probe and remove. In this
case they are passed the struct device of the IIO device that the driver
registers.

This works because in the `imx7d_adc_{enable,disable}()` functions the
passed struct device is only ever used as a parameter to `dev_get_drvdata()`
and `dev_get_drvdata()` returns the same value for the platform device and
the IIO device.

But for consistency we should pass the same struct device to the
`imx7d_adc_{enable,disable}()` in all cases. This will avoid accidental
breakage if the device is ever used for something more than
`dev_get_drvdata()`.

Another motivation is that `dev_get_drvdata()` on the IIO device relies on
the IIO core calling `dev_set_drvdata()`. Something we want to remove.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211020085754.16654-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: st-sensors: Use dev_to_iio_dev() in sysfs callbacks

Using `dev_get_drvdata()` in IIO sysfs callbacks to get a pointer to the
IIO device is a relic from the very early days of IIO. The IIO core as well
as most other drivers have switched over to using `dev_to_iio_dev()`
instead.

This driver is one of the last few drivers remaining that uses the outdated
idiom, update it. This will allow to eventually update the IIO core to no
longer set the drvdata for the IIO device and free it up for driver usage.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211020085349.16178-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: stm32-adc: Fix of_node_put() issue in stm32-adc

Fix following coccicheck warning:
./drivers/iio/adc/stm32-adc.c:2014:1-33: WARNING: Function
for_each_available_child_of_node should have of_node_put() before return.

Early exits from for_each_available_child_of_node should decrement the
node reference counter. Replace return by goto here.

Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Link: https://lore.kernel.org/r/20211021121826.6339-1-wanjiabing@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: xilinx-xadc: Make IRQ optional

In some setups the IRQ signal of the XADC might not be wired to the host
system. The driver currently requires that an interrupt is specified. Make
the interrupt optional so the driver can be used in such setups where the
interrupt is not connected.

Since both the internal triggers as well as events depend on the interrupt
being connected both are not available when the interrupt is not connected.

Buffered access is still supported even without an interrupt since an
external trigger can be used.

The IRQ is only optional when using the AXI interface, since the PCAP
interface needs the IRQ for reading and writing registers.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211021125950.28707-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: mma7660: Warn about failure to put device in stand-by in .remove()

Whan an i2c driver's remove function returns a non-zero error code
nothing happens apart from emitting a generic error message. Make this
error message more device specific and return zero instead.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211025195007.84541-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: lpc18xx_adc: Reorder clk_get_rate() function call

clk_get_rate() is not guaranteed to work if called before
clk_prepare_enable().

Reorder clk_get_rate(), so it's called after clk_prepare_enable() and
after devm_add_action_or_reset() of lpc18xx_clk_disable().

Not that this is not a problem on this particular device, but it is
good to remove a case that might get copied elsewhere.

Suggested-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: André Gustavo Nakagomi Lopez <andregnl@usp.br>
Link: https://lore.kernel.org/r/YXag5l4xBkGQH3tq@Andryuu.br
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Linux 5.16-rc1

kconfig: Add support for -Wimplicit-fallthrough

Add Kconfig support for -Wimplicit-fallthrough for both GCC and Clang.

The compiler option is under configuration CC_IMPLICIT_FALLTHROUGH,
which is enabled by default.

Special thanks to Nathan Chancellor who fixed the Clang bug[1][2]. This
bugfix only appears in Clang 14.0.0, so older versions still contain
the bug and -Wimplicit-fallthrough won't be enabled for them, for now.

This concludes a long journey and now we are finally getting rid
of the unintentional fallthrough bug-class in the kernel, entirely. :)

Link: https://github.com/llvm/llvm-project/commit/9ed4a94d6451046a51ef393cd62f00710820a7e8
Link: https://bugs.llvm.org/show_bug.cgi?id=51094
Link: https://github.com/KSPP/linux/issues/115
Link: https://github.com/ClangBuiltLinux/linux/issues/236
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'xfs-5.16-merge-5' of git://git./fs/xfs/xfs-linux

Pull xfs cleanups from Darrick Wong:
 "The most 'exciting' aspect of this branch is that the xfsprogs
  maintainer and I have worked through the last of the code
  discrepancies between kernel and userspace libxfs such that there are
  no code differences between the two except for #includes.

  IOWs, diff suffices to demonstrate that the userspace tools behave the
  same as the kernel, and kernel-only bits are clearly marked in the
  /kernel/ source code instead of just the userspace source.

  Summary:

   - Clean up open-coded swap() calls.

   - A little bit of #ifdef golf to complete the reunification of the
     kernel and userspace libxfs source code"

* tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: sync xfs_btree_split macros with userspace libxfs
  xfs: #ifdef out perag code for userspace
  xfs: use swap() to make dabtree code cleaner

Merge tag 'for-5.16/parisc-3' of git://git./linux/kernel/git/deller/parisc-linux

Pull more parisc fixes from Helge Deller:
 "Fix a build error in stracktrace.c, fix resolving of addresses to
  function names in backtraces, fix single-stepping in assembly code and
  flush userspace pte's when using set_pte_at()"

* tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc/entry: fix trace test in syscall exit path
  parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page
  parisc: Fix implicit declaration of function '__kernel_text_address'
  parisc: Fix backtrace to always include init funtion names