From: Jonathan Cameron <jic23@kernel.org>
To: linux-iio@vger.kernel.org,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: [PATCH v3 06/20] iio: dummy: Use a fixed structure to build up scan to push to buffers.
Date: Sun, 13 Apr 2025 11:34:29 +0100 [thread overview]
Message-ID: <20250413103443.2420727-7-jic23@kernel.org> (raw)
In-Reply-To: <20250413103443.2420727-1-jic23@kernel.org>
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It has long been discouraged for drivers to make use of iio_dev->scan_bytes
directly as that is an implementation detail of the core. As such our
example driver should definitely not be doing so.
In order to illustrate the more complex case, where a DMA safe buffer is
needed, continue to kzalloc() the storage (but with a structure definition
to provide an explicit data layout). Also add comments on when a DMA safe
buffer is necessary and the two common ways of obtaining one.
Whilst we have a mixture of signed and unsigned channels, the unsigned
channels have ranges that can be stored in a signed value - hence
use signed storage for all channels, simplifying the structure definition.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
v3: Go back to kzalloc but with a structure definition. (Andy)
v2: Add a comment about stack buffers not being DMA safe.
---
drivers/iio/dummy/iio_simple_dummy_buffer.c | 25 +++++++++++++++------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c b/drivers/iio/dummy/iio_simple_dummy_buffer.c
index 288880346707..d0a7343e1b35 100644
--- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
+++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
@@ -31,6 +31,11 @@ static const s16 fakedata[] = {
[DUMMY_INDEX_ACCELX] = 344,
};
+struct dummy_scan {
+ s16 data[ARRAY_SIZE(fakedata)];
+ aligned_s64 timestamp;
+};
+
/**
* iio_simple_dummy_trigger_h() - the trigger handler function
* @irq: the interrupt number
@@ -45,11 +50,18 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p)
{
struct iio_poll_func *pf = p;
struct iio_dev *indio_dev = pf->indio_dev;
+ struct dummy_scan *scan;
int i = 0, j;
- u16 *data;
- data = kzalloc(indio_dev->scan_bytes, GFP_KERNEL);
- if (!data)
+ /*
+ * Note that some buses such as SPI require DMA safe buffers which
+ * cannot be on the stack. Two easy ways to do this:
+ * - Local kzalloc (as done here)
+ * - A buffer at the end of the structure accessed via iio_priv()
+ * that is marked __aligned(IIO_DMA_MINALIGN).
+ */
+ scan = kzalloc(sizeof(*scan), GFP_KERNEL);
+ if (!scan)
goto done;
/*
@@ -69,13 +81,12 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p)
* constant table fakedata.
*/
iio_for_each_active_channel(indio_dev, j)
- data[i++] = fakedata[j];
+ scan->data[i++] = fakedata[j];
- iio_push_to_buffers_with_timestamp(indio_dev, data,
+ iio_push_to_buffers_with_timestamp(indio_dev, scan,
iio_get_time_ns(indio_dev));
- kfree(data);
-
+ kfree(scan);
done:
/*
* Tell the core we are done with this trigger and ready for the
--
2.49.0
next prev parent reply other threads:[~2025-04-13 10:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-13 10:34 [PATCH v3 00/20] IIO: Introduce iio_push_to_buffers_with_ts() taking an input buffer length argument Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 01/20] iio: adc: ad7266: Fix potential timestamp alignment issue Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 02/20] iio: adc: ad7768-1: Fix insufficient alignment of timestamp Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 03/20] iio: adc: dln2: Use aligned_s64 for timestamp Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 04/20] iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64 Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 05/20] iio: introduced iio_push_to_buffers_with_ts() that takes a data_total_len argument Jonathan Cameron
2025-04-13 10:34 ` Jonathan Cameron [this message]
2025-04-13 10:34 ` [PATCH v3 07/20] iio: dummy: Switch to iio_push_to_buffers_with_ts() and provide size of storage Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 08/20] iio: adc: ti-ads131e08: Use new iio_push_to_buffers_with_ts() to provide length sanity check Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 09/20] iio: adc: Use iio_push_to_buffers_with_ts() to provide length for runtime checks Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 10/20] iio: accel: " Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 11/20] iio: accel: hid: " Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 12/20] iio: chemical: " Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 13/20] iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 14/20] iio: temperature: Use iio_push_to_buffers_with_ts() to provide length for runtime checks Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 15/20] iio: resolver: " Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 16/20] iio: proximity: irsd200: Use a struct for scan and iio_push_to_buffers_with_ts() Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 17/20] iio: proximity: Use iio_push_to_buffers_with_ts() to provide length for runtime checks Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 18/20] iio: pressure: zpa2326: Use aligned_s64 for the timestamp Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 19/20] iio: pressure: Use iio_push_to_buffers_with_ts() to provide length for runtime checks Jonathan Cameron
2025-04-13 10:34 ` [PATCH v3 20/20] iio: magnetometer: " Jonathan Cameron
2025-04-16 23:48 ` [PATCH v3 00/20] IIO: Introduce iio_push_to_buffers_with_ts() taking an input buffer length argument David Lechner
2025-04-18 14:38 ` 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=20250413103443.2420727-7-jic23@kernel.org \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=linux-iio@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).