Validate the scan mask when SPI offloading is being used.
Since this family of ADCs is simultaneous sampling, there isn't a way
to selectively disable channels when reading sample data. (Technically,
AD7616 has a sequencer so the driver could have some control, but that
is for another day).
For "regular" IIO triggered buffer reads, this isn't a problem and the
IIO core will demux the data and ignore data from disabled channels.
However, since SPI offloading is done completely in hardware, we don't
have a way to do the same. So before this patch, if less than all
channels were enabled, the data would be misplaced in the buffer.
By adding a check in update_scan_mode, we can fail to enable the buffer
instead of having bad data returned to userspace.
Fixes: e96d35faf3 ("iio: adc: ad7606: add SPI offload support")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20250502-iio-adc-ad7606_spi-fix-offload-scan-mask-check-v2-1-e70c6d71baa3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drop the sensor_data array from struct bmp280_data and replace it using
local structs in each interrupt handler.
The sensor_data array in struct bmp280_data is not used to share data
between functions and isn't used for DMA, so there isn't really a need
to have it in the struct. Instead, we can use the struct pattern for
scan data in each interrupt handler. This has the advantage of allowing
us to see the actual layout of each scan buffer for each different type
of supported sensor. It also avoid juggling values between local
variables and the array which makes the code a bit simpler by avoiding
some extra assignments.
We can also drop the BME280_NUM_MAX_CHANNELS macro as it is no longer
used.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Link: https://lore.kernel.org/linux-iio/20250421135540.1a667221@jic23-huawei/
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250422-iio-pressure-bmp280-rework-push-to-buffers-v1-1-ee722f29aeca@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|hwfifo_timeout| is used by the EC firmware only when new samples are
available.
When the timeout changes, espcially when the new timeout is shorter than
the current one, send the samples waiting in the FIFO to the host.
Inline the call to transmit |hwfifo_timeout| value to the firmware.
Now flush when a sensor is suspended (ODR set to 0) as well.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://patch.msgid.link/20250423220506.2061021-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Consolidate duplicated logic from zopt2201_write_scale_als_by_idx() and
zopt2201_write_scale_uvb_by_idx() into a new generic helper function
zopt2201_write_scale_by_idx(). This function takes an additional
parameter: a pointer to a zopt2201_scale array.
To support this, the previously anonymous and duplicated struct used in
the scale arrays was promoted to a named struct: zopt2201_scale.
This change also corrects an incorrect array access that existed in
zopt2201_write_scale_uvb_by_idx().
Signed-off-by: Beatriz Viana Costa <beatrizvianacosta16@gmail.com>
Co-developed-by: Gabriela Victor <gabevictor333@gmail.com>
Signed-off-by: Gabriela Victor <gabevictor333@gmail.com>
Link: https://patch.msgid.link/20250424002144.23260-1-beatrizvianacosta16@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add oversampling support for STM32H7, STM32MP15 & STM32MP13.
STM32F4 ADC has no oversampling feature.
The current support of the oversampling feature aims at increasing the
data SNR, without changing the data resolution.
As the oversampling by itself increases data resolution, a right shift
is applied to keep the initial resolution.
Only the oversampling ratio corresponding to a power of two are
supported here, to get a direct link between right shift and
oversampling ratio. (2^n ratio <=> n right shift)
The oversampling ratio is shared by all channels, whatever channel type.
(e.g. single ended or differential).
Oversampling can be configured using IIO ABI:
- oversampling_ratio_available
- oversampling_ratio
Co-developed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250424151604.626758-1-olivier.moysan@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Set the suppress bit feature to the double tap detection, whenever
double tap is enabled. This impedes the suppress bit dangling in any
state, and thus varying in sensitivity for double tap detection.
Any tap event is defined by a rising signal edge above threshold, i.e.
duration time starts counting; and the falling edge under threshold
within duration time, i.e. then the tap event is issued. This means
duration is used individually for each tap event.
For double tap detection after a single tap, a latency time needs to be
specified. Usually tap events, i.e. spikes above and returning below
threshold will be ignored within latency. After latency, the window
time starts counting for a second tap detection which has to happen
within a duration time.
If the suppress bit is not set, spikes within latency time are ignored.
Setting the suppress bit will invalidate the double tap function. The
sensor will thus be able to save the window time for double tap
detection, and follow a more strict definition of what signal qualifies
for a double tap.
In a summary having the suppress bit set, fewer signal spikes will be
considered as double taps. This is an optional add on to double tap,
thus a separate patch.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Link: https://patch.msgid.link/20250414184245.100280-5-l.rubusch@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the double tap feature of the sensor. The interrupt handler needs
to catch and forward the event to the IIO channel. The single tap
implementation now is extended to deal with double tap as well.
Doubletap introduces window and latency times, both in us. Since both
times are scaled, the 8-bit register value is stored in hardware,
where the scaled value in [us] is stored as member variable.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Link: https://patch.msgid.link/20250414184245.100280-4-l.rubusch@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the single tap feature with a threshold in 62.5mg/LSB points and a
scaled duration in us. Keep singletap threshold in regmap cache but
the scaled value of duration in us as member variable.
Both use IIO channels for individual enable of the x/y/z axis. Initializes
threshold and duration with reasonable content. When an interrupt is
caught it will be pushed to the according IIO channel.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Link: https://patch.msgid.link/20250414184245.100280-3-l.rubusch@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Move the fifo handling into a separate function. This is a preparation
for a generic handling of the interrupt status register results. The
function is supposed to handle particular sensor events, and later to
forward them to the iio channel. This is needed to read out the interrupt
status register.
The function shall return occurring errors, if any, or 0 in case of
handled events or read fifo content. Thus migrate fifo read-out and push
fifo content to iio channels into this function to be built up with
additional event handling.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Link: https://patch.msgid.link/20250414184245.100280-2-l.rubusch@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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>
The driver previously used an array of two s64, then type cast the
pointer to write an s16 to the start. The code is made more readable
using a structure. At the same time switch to the new
iio_push_to_buffers_with_ts() helper to enable runtime checking of the
size of the source buffer.
Note that this approach uses a structure with holes, so use memset()
to ensure those do not contain old kernel data as this data is passed
to userspace.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250413103443.2420727-17-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
By providing the size of the buffer used, runtime checks can be performed
to ensure not overrun.
Also change the pushed data pointer to be that of the structure that also
contains the timestamp. Not an actual bug but semantically incorrect to
push the channel data when we want the storage with the timestamp as well.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250413103443.2420727-9-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It has long been discouraged for drivers to make use of iio_dev->scan_bytes
directly as that is an implementation detail of the core. As such our
example driver should definitely not be doing so.
In order to illustrate the more complex case, where a DMA safe buffer is
needed, continue to kzalloc() the storage (but with a structure definition
to provide an explicit data layout). Also add comments on when a DMA safe
buffer is necessary and the two common ways of obtaining one.
Whilst we have a mixture of signed and unsigned channels, the unsigned
channels have ranges that can be stored in a signed value - hence
use signed storage for all channels, simplifying the structure definition.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250413103443.2420727-7-jic23@kernel.org
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>
Fix Smatch-detected issue:
drivers/iio/adc/ad_sigma_delta.c:604 ad_sd_trigger_handler() error:
uninitialized symbol 'status_pos'.
The variable `status_pos` was only initialized in specific switch cases
(1, 2, 3, 4), which could leave it uninitialized if `reg_size` had an
unexpected value.
Fix by adding a default case to the switch block to catch unexpected
values of `reg_size`. Use `dev_err_ratelimited()` for error logging and
`goto irq_handled` instead of returning early.
Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
Link: https://patch.msgid.link/20250410170408.8585-1-purvayeshi550@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
