public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Eugen Hristev" <eugen.hristev@linaro.org>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/6] iio: introduce IIO_DECLARE_BUFFER_WITH_TS macros
Date: Sat, 26 Apr 2025 12:35:09 +0100	[thread overview]
Message-ID: <20250426123509.0b04f0f9@jic23-huawei> (raw)
In-Reply-To: <20250425-iio-introduce-iio_declare_buffer_with_ts-v3-1-f12df1bff248@baylibre.com>

On Fri, 25 Apr 2025 16:08:43 -0500
David Lechner <dlechner@baylibre.com> wrote:

> Add new macros to help with the common case of declaring a buffer that
> is safe to use with iio_push_to_buffers_with_ts(). This is not trivial
> to do correctly because of the alignment requirements of the timestamp.
> This will make it easier for both authors and reviewers.
> 
> To avoid double __align() attributes in cases where we also need DMA
> alignment, add a 2nd variant IIO_DECLARE_DMA_BUFFER_WITH_TS().
> 
Generally good.  A few little things though...

> Signed-off-by: David Lechner <dlechner@baylibre.com>
> ---
> 
> v3 changes:
> * Use leading double-underscore for "private" macro to match "private"
>   functions that do the same.
> * Use static_assert() from linux/build_bug.h instead of _Static_assert()
> * Fix incorrectly using sizeof(IIO_DMA_MINALIGN).
> * Add check that count argument is constant. (Note, I didn't include a
>   message in this static assert because it already gives a reasonable
>   message.)
> 
> /home/david/work/bl/linux/drivers/iio/accel/sca3300.c:482:51: error: expression in static assertion is not constant
>   482 |         IIO_DECLARE_BUFFER_WITH_TS(s16, channels, val);
>       |                                                   ^~~
> 
> v2 changes:
> * Add 2nd macro for DMA alignment
> ---
>  include/linux/iio/iio.h | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 638cf2420fbd85cf2924d09d061df601d1d4bb2a..1115b219271b76792539931edc404a67549bd8b1 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -7,6 +7,8 @@
>  #ifndef _INDUSTRIAL_IO_H_
>  #define _INDUSTRIAL_IO_H_
>  
> +#include <linux/align.h>
> +#include <linux/build_bug.h>
>  #include <linux/device.h>
>  #include <linux/cdev.h>
>  #include <linux/compiler_types.h>
> @@ -777,6 +779,42 @@ static inline void *iio_device_get_drvdata(const struct iio_dev *indio_dev)
>   * them safe for use with non-coherent DMA.
>   */
>  #define IIO_DMA_MINALIGN ARCH_DMA_MINALIGN
> +
> +#define __IIO_DECLARE_BUFFER_WITH_TS(type, name, count) \
> +	static_assert(count); \

Why do we care if count is 0?  Or is intent to check if is constant?
If the thought is we don't care either way about 0 (as rather nonsensical)
and this will fail to compile if not constant, then perhaps a comment would
avoid future confusion?

> +	type name[ALIGN((count), sizeof(s64) / sizeof(type)) + sizeof(s64) / sizeof(type)]
> +
> +/**
> + * IIO_DECLARE_BUFFER_WITH_TS() - Declare a buffer with timestamp
> + * @type: element type of the buffer
> + * @name: identifier name of the buffer
> + * @count: number of elements in the buffer
> + *
> + * Declares a buffer that is safe to use with iio_push_to_buffer_with_ts(). In
> + * addition to allocating enough space for @count elements of @type, it also
> + * allocates space for a s64 timestamp at the end of the buffer and ensures
> + * proper alignment of the timestamp.
> + */
> +#define IIO_DECLARE_BUFFER_WITH_TS(type, name, count) \
> +	__IIO_DECLARE_BUFFER_WITH_TS(type, name, count) __aligned(sizeof(s64))
> +
> +/**
> + * IIO_DECLARE_DMA_BUFFER_WITH_TS() - Declare a DMA-aligned buffer with timestamp
> + * @type: element type of the buffer
> + * @name: identifier name of the buffer
> + * @count: number of elements in the buffer
> + *
> + * Same as IIO_DECLARE_BUFFER_WITH_TS(), but is uses __aligned(IIO_DMA_MINALIGN)
> + * to ensure that the buffer doesn't share cachelines with anything that comes
> + * before it in a struct. This should not be used for stack-allocated buffers
> + * as stack memory cannot generally be used for DMA.
> + */
> +#define IIO_DECLARE_DMA_BUFFER_WITH_TS(type, name, count) \
> +	__IIO_DECLARE_BUFFER_WITH_TS(type, name, count) __aligned(IIO_DMA_MINALIGN)
> +
> +static_assert(IIO_DMA_MINALIGN % sizeof(s64) == 0,
That message isn't super helpful if seen in a compile log as we aren't reading the code here
"IIO_DECLARE_DMA_BUFFER_WITH_TS() assumes that ...

> +	"macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment");
> +
>  struct iio_dev *iio_device_alloc(struct device *parent, int sizeof_priv);
>  
>  /* The information at the returned address is guaranteed to be cacheline aligned */
> 



  reply	other threads:[~2025-04-26 11:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25 21:08 [PATCH v3 0/6] iio: introduce IIO_DECLARE_BUFFER_WITH_TS David Lechner
2025-04-25 21:08 ` [PATCH v3 1/6] iio: introduce IIO_DECLARE_BUFFER_WITH_TS macros David Lechner
2025-04-26 11:35   ` Jonathan Cameron [this message]
2025-04-26 22:34     ` David Lechner
2025-04-27 10:20       ` Jonathan Cameron
2025-04-26 19:15   ` kernel test robot
2025-04-27  1:54   ` kernel test robot
2025-04-25 21:08 ` [PATCH v3 2/6] iio: adc: ad4695: use u16 for buffer elements David Lechner
2025-04-25 21:08 ` [PATCH v3 3/6] iio: adc: ad4695: use IIO_DECLARE_DMA_BUFFER_WITH_TS David Lechner
2025-04-26 11:24   ` Jonathan Cameron
2025-04-25 21:08 ` [PATCH v3 4/6] iio: adc: ad7380: " David Lechner
2025-04-25 21:08 ` [PATCH v3 5/6] iio: accel: sca3300: use IIO_DECLARE_BUFFER_WITH_TS David Lechner
2025-04-25 21:08 ` [PATCH v3 6/6] iio: adc: at91-sama5d2: " David Lechner

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=20250426123509.0b04f0f9@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andy@kernel.org \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=dlechner@baylibre.com \
    --cc=eugen.hristev@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=nuno.sa@analog.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox