RE: [RFC PATCH 1/4] iio: core: Introduce iio_push_to_buffers_with_ts_na() for non aligned case.

From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: Jonathan Cameron <jic23@kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: RE: [RFC PATCH 1/4] iio: core: Introduce iio_push_to_buffers_with_ts_na() for non aligned case.
Date: Sun, 2 May 2021 09:10:56 +0000	[thread overview]
Message-ID: <PH0PR03MB6366C6AB21991C43CDF40B43995C9@PH0PR03MB6366.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20210501172515.513486-2-jic23@kernel.org>

> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Saturday, May 1, 2021 7:25 PM
> To: linux-iio@vger.kernel.org
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Subject: [RFC PATCH 1/4] iio: core: Introduce
> iio_push_to_buffers_with_ts_na() for non aligned case.
> 
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> 
> Whilst it is almost always possible to arrange for scan data to be
> read directly into a buffer that is suitable for passing to
> iio_push_to_buffers_with_timestamp(), there are a few places where
> leading data needs to be skipped over.
> 
> For these cases introduce a function that will allocate an appropriate
> sized and aligned bounce buffer (if not already allocated) and copy
> the unaligned data into that before calling
> iio_push_to_buffers_with_timestamp() on the bounce buffer.
> We tie the lifespace of this buffer to that of the iio_dev.dev
> which should ensure no memory leaks occur.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>  drivers/iio/industrialio-buffer.c | 36
> +++++++++++++++++++++++++++++++
>  include/linux/iio/buffer.h        |  4 ++++
>  include/linux/iio/iio-opaque.h    |  4 ++++
>  3 files changed, 44 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> buffer.c
> index 9a8e16c7e9af..818dfaa73665 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -1727,6 +1727,42 @@ int iio_push_to_buffers(struct iio_dev
> *indio_dev, const void *data)
>  }
>  EXPORT_SYMBOL_GPL(iio_push_to_buffers);
> 
> +/**
> + * iio_push_to_buffers_with_ts_na() - push to registered buffer,
> + *    no alignment or space requirements.
> + * @indio_dev:		iio_dev structure for device.
> + * @data:		channel data excluding the timestamp.
> + * @data_sz:		size of data.
> + * @timestamp:		timestamp for the sample data.
> + *
> + * This special variant of iio_push_to_buffers_with_timetamp() does
> + * not require space for the timestamp, or 8 byte alignment of data.
> + * It does however require an allocation on first call and additional
> + * coppies on all calls, so should be avoided if possible
> + */
> +int iio_push_to_buffers_with_ts_na(struct iio_dev *indio_dev,
> +				   const void *data,
> +				   size_t data_sz,
> +				   int64_t timestamp)
> +{
> +	struct iio_dev_opaque *iio_dev_opaque =
> to_iio_dev_opaque(indio_dev);
> +
> +	data_sz = min_t(size_t, indio_dev->scan_bytes, data_sz);
I'm not really sure  about this. Is it really a good idea to silently truncate
the data if some erroneous driver calls this with data_sz > scan_bytes?
(I don't think it's ever valid for data_sz to be bigger than scan_bytes)
We might be discarding data that userland actually requested. So, I'm
not sure if it would not be better to be strict here and return error, so that
driver developers could catch this early on...

data_sz < scan_bytes is also probably not valid as that might happen
if some drivers call this without the scan elements properly aligned
which will definitely be problematic... Naturally in this case we would
have to take into account timestamp possible alignment fill bytes as it
could be possible (and likely) that data_sz won't include those bits...

Alternatively, we could be consistent with 'iio_push_to_buffers_with_timestamp()'
and assume drivers play along in terms of alignment and size
(so, removing the data_sz parameter)...

My point is, if we are taking the data_sz parameter, maybe we should be pedantic
about it...
> +	if (iio_dev_opaque->bounce_buffer_size !=  indio_dev-
> >scan_bytes) {

Where do we set ' bounce_buffer_size '? I guess we do not want to
get  here all the time...
> +		iio_dev_opaque->bounce_buffer =
> +			devm_krealloc(&indio_dev->dev,
> +				      iio_dev_opaque->bounce_buffer,
> +				      indio_dev->scan_bytes,
> GFP_KERNEL);

I'm also not a big fan of realloc so I prefer to avoid it unless really needed...
Here, maybe we could just allocate this once during device/buffer initialization
and allocate it for the maximum possible size, i.e all scan elements enabled...
That could also make this API simpler to the point of actually be inlined...

- Nuno Sá