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