On Sun, 2025-03-09 at 18:20 +0000, Jonathan Cameron wrote:
> From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
>
> Check that total_len argument against iio_dev->scan_bytes.
>
> The size needs to be at least as big as the scan. It can be larger,
> which is typical if only part of fixed sized storage is used due to
> a subset of channels being enabled.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> ---
> include/linux/iio/buffer.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/linux/iio/buffer.h b/include/linux/iio/buffer.h
> index 3b8d618bb3df..75d5e58b646b 100644
> --- a/include/linux/iio/buffer.h
> +++ b/include/linux/iio/buffer.h
> @@ -45,6 +45,19 @@ static inline int iio_push_to_buffers_with_timestamp(struct
> iio_dev *indio_dev,
> return iio_push_to_buffers(indio_dev, data);
> }
>
> +static inline int iio_push_to_buffers_with_ts(struct iio_dev *indio_dev,
> + void *data, size_t total_len,
> + int64_t timestamp)
> +{
Kind of a nitpick but what about data_len as the size relate to *data?
> + if (total_len < indio_dev->scan_bytes) {
Given this is to be called on a fastpath and that the above is clearly a bug,
what do you think about unlikely(total_len < indio_dev->scan_bytes) for some
micro optimization?
Anyways, this looks like a nice API improvement to me!
- Nuno Sá
>
