All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: Jonathan Cameron <jic23@kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: RE: [PATCH v2 1/4] iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()
Date: Mon, 14 Jun 2021 08:33:38 +0000	[thread overview]
Message-ID: <PH0PR03MB6366316685FFF56C4EDC660C99319@PH0PR03MB6366.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20210613151039.569883-2-jic23@kernel.org>

> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Sunday, June 13, 2021 5:11 PM
> To: linux-iio@vger.kernel.org; Andy Shevchenko
> <andy.shevchenko@gmail.com>; Sa, Nuno <Nuno.Sa@analog.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>; Jan Kiszka
> <jan.kiszka@siemens.com>; Jonathan Cameron
> <Jonathan.Cameron@huawei.com>
> Subject: [PATCH v2 1/4] iio: core: Introduce
> iio_push_to_buffers_with_ts_unaligned()
> 
> [External]
> 
> 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 | 46
> +++++++++++++++++++++++++++++++
>  include/linux/iio/buffer.h        |  4 +++
>  include/linux/iio/iio-opaque.h    |  4 +++
>  3 files changed, 54 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> buffer.c
> index fdd623407b96..5241b5a5c6c0 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -1730,6 +1730,52 @@ 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_unaligned() - 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_timestamp() does
> + * not require space for the timestamp, or 8 byte alignment of data.
> + * It does however require an allocation on first call and additional
> + * copies on all calls, so should be avoided if possible.
> + */
> +int iio_push_to_buffers_with_ts_unaligned(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);
> +
> +	/*
> +	 * Conservative estimate - we can always safely copy the
> minimum
> +	 * of either the data provided or the length of the destination
> buffer.
> +	 * This relaxed limit allows the calling drivers to be lax about
> +	 * tracking the size of the data they are pushing, at the cost of
> +	 * unnecessary copying of padding.
> +	 */
> +	data_sz = min_t(size_t, indio_dev->scan_bytes, data_sz);

Well, As I said in the RFC: "I still feel that if we are taking the data_sz parameter on
the API, we should handle it more strictly. But I do not feel too strong about this (as
you said, It's not expected to exist too much users of this)..." :). And we can always
become more "strict" if we start to see people doing really bad things... So, as you
said, most likely we won't have much benefit from the added complexity.

Being this said:

Reviewed-by: Nuno Sá <nuno.sa@analog.com>

- Nuno Sá

  reply	other threads:[~2021-06-14  8:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-13 15:10 [PATCH v2 0/4] IIO: Alignment fixes part 4 - bounce buffers for the hard cases Jonathan Cameron
2021-06-13 15:10 ` [PATCH v2 1/4] iio: core: Introduce iio_push_to_buffers_with_ts_unaligned() Jonathan Cameron
2021-06-14  8:33   ` Sa, Nuno [this message]
2021-06-13 15:10 ` [PATCH v2 2/4] iio: adc: ti-adc108s102: Fix alignment of buffer pushed to iio buffers Jonathan Cameron
2021-06-13 15:10 ` [PATCH v2 3/4] iio: gyro: mpu3050: Fix alignment and size issues with buffers Jonathan Cameron
2021-06-13 15:10 ` [PATCH v2 4/4] iio: imu: adis16400: Fix buffer alignment requirements Jonathan Cameron
2021-06-14  8:25   ` Sa, Nuno
2021-07-18 14:55 ` [PATCH v2 0/4] IIO: Alignment fixes part 4 - bounce buffers for the hard cases Jonathan Cameron
2021-10-03 15:54   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PH0PR03MB6366316685FFF56C4EDC660C99319@PH0PR03MB6366.namprd03.prod.outlook.com \
    --to=nuno.sa@analog.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jic23@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.