Follow the pattern of other drivers and use aligned_s64 for the
timestamp. Technically there was no issue here since
AD74413R_FRAME_SIZE * AD74413R_CHANNEL_MAX == 16 and IIO_DMA_MINALIGN
is always a multiple of 8. But best to conform in case someone copies
this to new code and then tweaks something.
Also move the unaligned.h header while touching this since it was the
only one not in alphabetical order.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-3-eafac1e22318@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use `\t(\{ ?\},|\{\}|\{\s*/\*.*\*/\s*\},?)$` regex to find and replace
the array sentinel in all IIO drivers to the same style.
For some time, we've been trying to consistently use `{ }` (no trailing
comma, no comment, one space between braces) for array sentinels in the
IIO subsystem. Still nearly 50% of existing code uses a different style.
To save reviewers from having to request this trivial change as
frequently, let's normalize the style in all existing IIO drivers.
At least when code is copy/pasted to new drivers, the style will be
consistent.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250411-iio-sentinel-normalization-v1-1-d293de3e3d93@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20250409-gpiochip-set-rv-iio-v2-6-4b36428f39cb@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This complex cleanup.h use case of conditional guards has proved
to be more trouble that it is worth in terms of false positive compiler
warnings and hard to read code.
Move directly to the new claim/release_direct() that allow sparse
to check for unbalanced context. Includes moving a mutex lock
into a function rather than around it to simplify the error handling.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20250209180624.701140-21-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make use of mutex guard() and IIO iio_device_claim_direct_scoped() to
simplify code and error handling.
While at it, use devm_mutex_init() to initialize the mutex.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20241016-dev-ad74413r-minor-improv-v1-3-13c9c769237d@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It's highly unlikely for the converter ref voltage to change at runtime.
Hence, let's read the voltage and save it (instead of the regulator
struct). While at it, simplify the code by using
devm_regulator_get_enable_read_voltage().
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20241016-dev-ad74413r-minor-improv-v1-2-13c9c769237d@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We just need the reset gpio during probe so there's no need to keep it
in our state struct. Hence, move devm_gpiod_get_optional() into
ad74413r_reset() and use a local struct gpio_desc.
While at it, request the gpio in the asserted state (GPIOD_OUT_HIGH) so
that we already perform the reset while requesting the gpio saving us a
call to gpiod_set_value_cansleep().
Also, explicitly include <gpio/consumer.h> for
devm_gpiod_get_optional().
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20241016-dev-ad74413r-minor-improv-v1-1-13c9c769237d@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmcDD/seHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGNpoH/3oEXaHBl5wrRJKP
GpzfT35Do052IZnRl0dmanr92opV5O7R4esVyHIS4IOKkt7C2aEEoVrMKAqW/VH9
EkcLPJwOuJ1xyqnLWycQUEN/JK9hxM9DlAVUVg9JdbDE4b91ebwTivwJMTJ7tQwm
+P/ifzV1r4fsYgpasqwVQMwLWuZ8O6OCGXE4KlgwiaS5zLdiVG+zkvvli/x/YHQ9
dPgQ+OXyoQz57Iwj02ZHBkdqJxa9vPVPASjtzuRp0v7VGaMq8gvVH8pA4B7cGjfV
xWvT+sjYjXVltYfmUHgUDNNTfeJArxH+BqpJ+lShcYwjxomYFfJWT0KZOPQwg/3z
zfAZtk4=
=RHAh
-----END PGP SIGNATURE-----
Merge tag 'v6.12-rc2' into test2
Linux 6.12-rc2
Resolved movement of asm/unaligned.h to linux/unaligned.h
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
'struct iio_chan_spec' are not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
35749 5879 384 42012 a41c drivers/iio/addac/ad74115.o
32242 3297 384 35923 8c53 drivers/iio/addac/ad74413r.o
After:
=====
text data bss dec hex filename
39109 2519 384 42012 a41c drivers/iio/addac/ad74115.o
33842 1697 384 35923 8c53 drivers/iio/addac/ad74413r.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/da291278e78b983ea2e657a25769f7d82ea2a6d0.1725717045.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use spi_get_device_match_data() helper to simplify a bit the driver.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-6-320b291ee1fe@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Switching to the _scoped() version removes the need for manual
calling of fwnode_handle_put() in the paths where the code
exits the loop early. In this case that's all in error paths.
The use of fwnode_for_each_available_child_node() here is assumed
to have been down to a false assumption that device_for_each_child_node()
doesn't check avaialble - so this transition to the scoped
device_for_each_child_node_scoped() is equivalent.
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240217164249.921878-13-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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>
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>
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: 504eb48558 (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>
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: fea251b6a5 (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>
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>
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>
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>
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>
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: fea251b6a5 (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>
____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: fea251b6a5 ("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
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>
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: fea251b6a5 ("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>
ngpio is the actual number of GPIOs handled by the GPIO chip,
as opposed to the max number of GPIOs.
Fixes: fea251b6a5 ("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>
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: 5d97d9e9a7 ("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
The > needs to be >= to prevent accessing one element beyond the end of
the st->channel_configs[] array.
Fixes: fea251b6a5 ("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>
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>
