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().
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); \
+ 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,
+ "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 */
--
2.43.0Hi David, kernel test robot noticed the following build warnings: [auto build test WARNING on aff301f37e220970c2f301b5c65a8bfedf52058e] url: https://github.com/intel-lab-lkp/linux/commits/David-Lechner/iio-introduce-IIO_DECLARE_BUFFER_WITH_TS-macros/20250426-051240 base: aff301f37e220970c2f301b5c65a8bfedf52058e patch link: https://lore.kernel.org/r/20250425-iio-introduce-iio_declare_buffer_with_ts-v3-1-f12df1bff248%40baylibre.com patch subject: [PATCH v3 1/6] iio: introduce IIO_DECLARE_BUFFER_WITH_TS macros config: i386-randconfig-r133-20250427 (https://download.01.org/0day-ci/archive/20250427/202504270919.3FGvikEj-lkp@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250427/202504270919.3FGvikEj-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202504270919.3FGvikEj-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/iio/accel/adxl313_core.c: note: in included file (through drivers/iio/accel/adxl313.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl345_core.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl355_core.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl313_spi.c: note: in included file (through drivers/iio/accel/adxl313.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adis16201.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adis16209.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/dmard09.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/da311.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl313_i2c.c: note: in included file (through drivers/iio/accel/adxl313.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl367_spi.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/da280.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/kxsd9.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/bma220_spi.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/kionix-kx022a.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl372.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/kxcjk-1013.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/fxls8962af-core.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl380.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/adxl367.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mma7455_core.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mc3230.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/ssp_accel_sensor.c: note: in included file (through include/linux/iio/common/ssp_sensors.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mma7660.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/sca3300.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mma9551.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mma9551_core.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mxc4005.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/stk8312.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/stk8ba50.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/sca3000.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/msa311.c: note: in included file (through include/linux/iio/buffer.h): >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" -- drivers/iio/accel/mma9553.c: note: in included file: >> include/linux/iio/iio.h:815:1: sparse: sparse: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment" vim +815 include/linux/iio/iio.h 782 783 #define __IIO_DECLARE_BUFFER_WITH_TS(type, name, count) \ 784 static_assert(count); \ 785 type name[ALIGN((count), sizeof(s64) / sizeof(type)) + sizeof(s64) / sizeof(type)] 786 787 /** 788 * IIO_DECLARE_BUFFER_WITH_TS() - Declare a buffer with timestamp 789 * @type: element type of the buffer 790 * @name: identifier name of the buffer 791 * @count: number of elements in the buffer 792 * 793 * Declares a buffer that is safe to use with iio_push_to_buffer_with_ts(). In 794 * addition to allocating enough space for @count elements of @type, it also 795 * allocates space for a s64 timestamp at the end of the buffer and ensures 796 * proper alignment of the timestamp. 797 */ 798 #define IIO_DECLARE_BUFFER_WITH_TS(type, name, count) \ 799 __IIO_DECLARE_BUFFER_WITH_TS(type, name, count) __aligned(sizeof(s64)) 800 801 /** 802 * IIO_DECLARE_DMA_BUFFER_WITH_TS() - Declare a DMA-aligned buffer with timestamp 803 * @type: element type of the buffer 804 * @name: identifier name of the buffer 805 * @count: number of elements in the buffer 806 * 807 * Same as IIO_DECLARE_BUFFER_WITH_TS(), but is uses __aligned(IIO_DMA_MINALIGN) 808 * to ensure that the buffer doesn't share cachelines with anything that comes 809 * before it in a struct. This should not be used for stack-allocated buffers 810 * as stack memory cannot generally be used for DMA. 811 */ 812 #define IIO_DECLARE_DMA_BUFFER_WITH_TS(type, name, count) \ 813 __IIO_DECLARE_BUFFER_WITH_TS(type, name, count) __aligned(IIO_DMA_MINALIGN) 814 > 815 static_assert(IIO_DMA_MINALIGN % sizeof(s64) == 0, 816 "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment"); 817 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Hi David,
kernel test robot noticed the following build errors:
[auto build test ERROR on aff301f37e220970c2f301b5c65a8bfedf52058e]
url: https://github.com/intel-lab-lkp/linux/commits/David-Lechner/iio-introduce-IIO_DECLARE_BUFFER_WITH_TS-macros/20250426-051240
base: aff301f37e220970c2f301b5c65a8bfedf52058e
patch link: https://lore.kernel.org/r/20250425-iio-introduce-iio_declare_buffer_with_ts-v3-1-f12df1bff248%40baylibre.com
patch subject: [PATCH v3 1/6] iio: introduce IIO_DECLARE_BUFFER_WITH_TS macros
config: openrisc-randconfig-r053-20250427 (https://download.01.org/0day-ci/archive/20250427/202504270311.4lppXI1u-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 10.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250427/202504270311.4lppXI1u-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504270311.4lppXI1u-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/container_of.h:5,
from include/linux/list.h:5,
from include/linux/kobject.h:19,
from include/linux/cdev.h:5,
from drivers/iio/industrialio-core.c:13:
>> include/linux/build_bug.h:78:41: error: static assertion failed: "macros above assume that IIO_DMA_MINALIGN also ensures s64 timestamp alignment"
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~~~~~~~~~~~
include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert'
77 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
| ^~~~~~~~~~~~~~~
include/linux/iio/iio.h:815:1: note: in expansion of macro 'static_assert'
815 | static_assert(IIO_DMA_MINALIGN % sizeof(s64) == 0,
| ^~~~~~~~~~~~~
vim +78 include/linux/build_bug.h
bc6245e5efd70c Ian Abbott 2017-07-10 60
6bab69c65013be Rasmus Villemoes 2019-03-07 61 /**
6bab69c65013be Rasmus Villemoes 2019-03-07 62 * static_assert - check integer constant expression at build time
6bab69c65013be Rasmus Villemoes 2019-03-07 63 *
6bab69c65013be Rasmus Villemoes 2019-03-07 64 * static_assert() is a wrapper for the C11 _Static_assert, with a
6bab69c65013be Rasmus Villemoes 2019-03-07 65 * little macro magic to make the message optional (defaulting to the
6bab69c65013be Rasmus Villemoes 2019-03-07 66 * stringification of the tested expression).
6bab69c65013be Rasmus Villemoes 2019-03-07 67 *
6bab69c65013be Rasmus Villemoes 2019-03-07 68 * Contrary to BUILD_BUG_ON(), static_assert() can be used at global
6bab69c65013be Rasmus Villemoes 2019-03-07 69 * scope, but requires the expression to be an integer constant
6bab69c65013be Rasmus Villemoes 2019-03-07 70 * expression (i.e., it is not enough that __builtin_constant_p() is
6bab69c65013be Rasmus Villemoes 2019-03-07 71 * true for expr).
6bab69c65013be Rasmus Villemoes 2019-03-07 72 *
6bab69c65013be Rasmus Villemoes 2019-03-07 73 * Also note that BUILD_BUG_ON() fails the build if the condition is
6bab69c65013be Rasmus Villemoes 2019-03-07 74 * true, while static_assert() fails the build if the expression is
6bab69c65013be Rasmus Villemoes 2019-03-07 75 * false.
6bab69c65013be Rasmus Villemoes 2019-03-07 76 */
6bab69c65013be Rasmus Villemoes 2019-03-07 77 #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
6bab69c65013be Rasmus Villemoes 2019-03-07 @78 #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
6bab69c65013be Rasmus Villemoes 2019-03-07 79
07a368b3f55a79 Maxim Levitsky 2022-10-25 80
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
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 */ >
On 4/26/25 6:35 AM, Jonathan Cameron wrote: > On Fri, 25 Apr 2025 16:08:43 -0500 > David Lechner <dlechner@baylibre.com> wrote: > ... >> @@ -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? I would be inclined to just leave out the check. But yes, it is just checking that count is constant and we don't expect 0. > >> + 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"); >> + Seems we actually have an arch (openrisc) that triggers this [1]. This arch doesn't define ARCH_DMA_MINALIGN so it falls back to: #define ARCH_DMA_MINALIGN __alignof__(unsigned long long) Apparently this is only of those 32-bit arches that only does 4 byte alignment. From the official docs [2]: Current OR32 implementations (OR1200) do not implement 8 byte alignment, but do require 4 byte alignment. Therefore the Application Binary Interface (chapter 16) uses 4 byte alignment for 8 byte types. Future extensions such as ORVDX64 may require natural alignment. [1]: https://lore.kernel.org/linux-iio/20250425-iio-introduce-iio_declare_buffer_with_ts-v3-0-f12df1bff248@baylibre.com/T/#m91e0332673438793ff76949037ff40a34765ca30 [2]: https://openrisc.io/or1k.html It looks like this could work (it compiles for me): __aligned(MAX(IIO_DMA_MINALIGN, sizeof(s64))) If that is OK we could leave out the static_assert(), unless we think there could be an arch with IIO_DMA_MINALIGN not a power of 2?!
On Sat, 26 Apr 2025 17:34:10 -0500 David Lechner <dlechner@baylibre.com> wrote: > On 4/26/25 6:35 AM, Jonathan Cameron wrote: > > On Fri, 25 Apr 2025 16:08:43 -0500 > > David Lechner <dlechner@baylibre.com> wrote: > > > > ... > > >> @@ -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? > > I would be inclined to just leave out the check. But yes, it is just checking > that count is constant and we don't expect 0. > > > > >> + 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"); > >> + > > Seems we actually have an arch (openrisc) that triggers this [1]. This arch > doesn't define ARCH_DMA_MINALIGN so it falls back to: > > #define ARCH_DMA_MINALIGN __alignof__(unsigned long long) > > Apparently this is only of those 32-bit arches that only does 4 byte alignment. > From the official docs [2]: > > Current OR32 implementations (OR1200) do not implement 8 byte alignment, > but do require 4 byte alignment. Therefore the Application Binary > Interface (chapter 16) uses 4 byte alignment for 8 byte types. Future > extensions such as ORVDX64 may require natural alignment. > > [1]: https://lore.kernel.org/linux-iio/20250425-iio-introduce-iio_declare_buffer_with_ts-v3-0-f12df1bff248@baylibre.com/T/#m91e0332673438793ff76949037ff40a34765ca30 > [2]: https://openrisc.io/or1k.html > > > It looks like this could work (it compiles for me): > > __aligned(MAX(IIO_DMA_MINALIGN, sizeof(s64))) > > If that is OK we could leave out the static_assert(), unless we think there > could be an arch with IIO_DMA_MINALIGN not a power of 2?! > That change seems fine. Non power of 2 arch would be fun but implausible any time soon :)
© 2016 - 2026 Red Hat, Inc.