iio: addac: ad74413r: update channel function set

According to the datasheet switching to a new channel function implies
multiple steps.

All functions must be selected for a minimum of 130 μs before changing
to another function.
The DAC_CODEx registers are not reset by changing channel functions.
Prior to changing channel functions, it is recommended to set the DAC
code to 0x0000 via the DAC_CODEx registers. Set the channel function
to high impedance via the CH_FUNC_SETUPx registers before transitioning
to the new channel function. After the new channel function is configured,
it is recommended to wait 150 μs before updating the DAC code.

Even though the channel switch is done at only at probe, where a device
reset is performed, that does not guarantee that the steps prior
changing to new channel function should be neglected.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://lore.kernel.org/r/20230911142950.216687-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: fix function prefix typo

Use complete device name prefix in the input current offset getter
function.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230830094314.26353-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413: don't set DIN_SINK for functions other than digital input

Apparently, despite the name Digital Input Configuration Register, the
settings in the DIN_CONFIGx registers also affect other channel
functions. In particular, setting a non-zero value in the DIN_SINK
field breaks the resistance measurement function.

Now, one can of course argue that specifying a drive-strength-microamp
property along with a adi,ch-func which is not one of the digital
input functions is a bug in the device tree. However, we have a rather
complicated setup with instances of ad74412r on external hardware
modules, and have set a default drive-strength-microamp in our DT
fragments describing those, merely modifying the adi,ch-func settings
to reflect however the modules have been wired up. And restricting
this setting to just being done for digital input doesn't make the
driver any more complex.

Fixes: 504eb485589d1 (iio: ad74413r: wire up support for drive-strength-microamp property)
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20230503105042.453755-1-linux@rasmusvillemoes.dk
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413: fix resistance input processing

On success, ad74413r_get_single_adc_result() returns IIO_VAL_INT aka
1. So currently, the IIO_CHAN_INFO_PROCESSED case is effectively
equivalent to the IIO_CHAN_INFO_RAW case, and we never call
ad74413r_adc_to_resistance_result() to convert the adc measurement to
ohms.

Check ret for being negative rather than non-zero.

Fixes: fea251b6a5dbd (iio: addac: add AD74413R driver)
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230503095817.452551-1-linux@rasmusvillemoes.dk
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: fix Current Input, Loop Powered Mode

Currently, the driver handles CH_FUNC_CURRENT_INPUT_LOOP_POWER and
CH_FUNC_CURRENT_INPUT_EXT_POWER completely identically. But that's not
correct. In order for CH_FUNC_CURRENT_INPUT_LOOP_POWER to work, two
changes must be made:

(1) expose access to the DAC_CODE_x register so that the intended
output current can be set, i.e. expose the channel as both current
output and current input, and

(2) per the data sheet

When selecting the current input loop powered function, tie the
VIOUTN_x pin to ground via the on-chip 200 kΩ resistor by enabling
the CH_200K_TO_GND bit in the ADC_CONFIGx registers.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20230301115511.849418-1-linux@rasmusvillemoes.dk
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ad74413r: wire up support for drive-strength-microamp property

Use the value specified in the channel configuration node to populate
the DIN_SINK field of the DIN_CONFIGx register.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20230306094301.1357543-3-linux@rasmusvillemoes.dk
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: fix blank line after declaration warning

Checkpatch wants a blank line after all declarations. Add it now,
even though the patch has already been submitted.

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

iio: addac: ad74413r: add support for reset-gpio

We have a board where the reset pin of the ad74412 is connected to a
gpio, but also pulled low (i.e., asserted) by default. Hence to get
the chip out of reset, the driver needs to know about that gpio and
deassert the reset signal before attempting to communicate with the
chip.

When a reset-gpio is given in device tree, use that instead of the
software reset. According to the data sheet, the two methods are
functionally equivalent.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20221115095517.1008632-4-linux@rasmusvillemoes.dk
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: add spi_device_id table

Silence the run-time warning

SPI driver ad74413r has no spi_device_id for adi,ad74412r

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20221115095517.1008632-2-linux@rasmusvillemoes.dk
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: fix integer promotion bug in ad74413_get_input_current_offset()

The constant AD74413R_ADC_RESULT_MAX is defined via GENMASK, so its
type is "unsigned long".

Hence in the expression voltage_offset * AD74413R_ADC_RESULT_MAX,
voltage_offset is first promoted to unsigned long, and since it may be
negative, that results in a garbage value. For example, when range is
AD74413R_ADC_RANGE_5V_BI_DIR, voltage_offset is -2500 and
voltage_range is 5000, so the RHS of this assignment is, depending on
sizeof(long), either 826225UL or 3689348814709142UL, which after
truncation to int then results in either 826225 or 1972216214 being
the output from in_currentX_offset.

Casting to int avoids that promotion and results in the correct -32767
output.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Fixes: fea251b6a5db (iio: addac: add AD74413R driver)
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221118123209.1658420-1-linux@rasmusvillemoes.dk
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: Fix alignment for DMA safety

____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.

Update the comment to include 'may'.

Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Cosmin Tanislav <cosmin.tanislav@analog.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20220508175712.647246-41-jic23@kernel.org

iio: addac: ad74413r: for_each_set_bit_from -> for_each_set_bit

The starting bit is always zero, it doesn't make much sense to
use for_each_set_bit_from. Replace it with for_each_set_bit
which doesn't start from a particular bit.

Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220111074703.3677392-3-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: correct comparator gpio getters mask usage

The value of the GPIOs is currently altered using offsets rather
than masks. Make use of __assign_bit and the BIT macro to turn
the offsets into masks.

Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220111074703.3677392-2-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: use ngpio size when iterating over mask

ngpio is the actual number of GPIOs handled by the GPIO chip,
as opposed to the max number of GPIOs.

Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220111074703.3677392-1-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: addac: ad74413r: Do not reference negative array offsets

Instead of aiming rx_buf at an invalid array-boundary-crossing location,
just skip the first increment. Seen when building with -Warray-bounds:

drivers/iio/addac/ad74413r.c: In function 'ad74413r_update_scan_mode':
drivers/iio/addac/ad74413r.c:843:22: warning: array subscript -4 is below array bounds of 'u8[16]' { aka 'unsigned char[16]'} [-Warray-bounds]
843 | u8 *rx_buf = &st->adc_samples_buf.rx_buf[-1 * AD74413R_FRAME_SIZE];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/iio/addac/ad74413r.c:84:20: note: while referencing 'rx_buf'
84 | u8 rx_buf[AD74413R_FRAME_SIZE * AD74413R_CHANNEL_MAX];
| ^~~~~~

Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Reviewed-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220112203456.3950884-1-keescook@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:addac:ad74413r: Fix uninitialized ret in a path that won't be hit.

I don't believe it's possible to hit this, because we drop
out of __iio_update_buffers() earlier in the event of an empty
list. However, that is not visible to the compiler so lets
return an error if we do hit the loop with an empty bitmask.

Fixes: 5d97d9e9a703 ("iio: addac: ad74413r: fix off by one in ad74413r_parse_channel_config()")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20211220164726.3136307-1-jic23@kernel.org

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: 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>