From: Jonathan Cameron <jic23@kernel.org>
To: Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org>
Cc: <nuno.sa@analog.com>,
linux-iio@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
Denis Ciocca <denis.ciocca@st.com>
Subject: Re: [PATCH] iio: commom: st_sensors: ensure proper DMA alignment
Date: Sat, 27 Jan 2024 15:56:55 +0000 [thread overview]
Message-ID: <20240127155655.6495b465@jic23-huawei> (raw)
In-Reply-To: <20240122-dev_dma_safety_stm-v1-1-3a021614cbfb@analog.com>
On Mon, 22 Jan 2024 15:15:41 +0100
Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> wrote:
> From: Nuno Sa <nuno.sa@analog.com>
>
> Aligning the buffer to the L1 cache is not sufficient in some platforms
> as they might have larger cacheline sizes for caches after L1 and thus,
> we can't guarantee DMA safety.
>
> That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same
> for st_sensors common buffer.
>
> [1]: https://lore.kernel.org/linux-iio/20220508175712.647246-2-jic23@kernel.org/
>
> Fixes: e031d5f558f1 ("iio:st_sensors: remove buffer allocation at each buffer enable")
> Signed-off-by: Nuno Sa <nuno.sa@analog.com>
> ---
> include/linux/iio/common/st_sensors.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/iio/common/st_sensors.h b/include/linux/iio/common/st_sensors.h
> index 607c3a89a647..a02652cf4862 100644
> --- a/include/linux/iio/common/st_sensors.h
> +++ b/include/linux/iio/common/st_sensors.h
> @@ -258,7 +258,7 @@ struct st_sensor_data {
> bool hw_irq_trigger;
> s64 hw_timestamp;
>
> - char buffer_data[ST_SENSORS_MAX_BUFFER_SIZE] ____cacheline_aligned;
> + char buffer_data[ST_SENSORS_MAX_BUFFER_SIZE] __aligned(IIO_DMA_MINALIGN);
>
> struct mutex odr_lock;
Hi Nuno.
This is another problem. There should be nothing after a DMA safe buffer embedded
in a structure like we do here. We rely on C structure padding to ensure the
rest of the __aligned(IIO_DMA_MINALIGN) region is unused and that doesn't work
if the buffer isn't the last element.
My guess is we are safe to just reorder this before the buffer.
Nuno, do you mind spinning a v2 that does that as well as the size change.
Jonathan
> };
>
> ---
> base-commit: f9c0358aadcba16d04d139a5412b413eeee87afe
> change-id: 20240122-dev_dma_safety_stm-c7016673f4ec
> --
>
> Thanks!
> - Nuno Sá
>
next prev parent reply other threads:[~2024-01-27 15:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 14:15 [PATCH] iio: commom: st_sensors: ensure proper DMA alignment Nuno Sa via B4 Relay
2024-01-27 15:56 ` Jonathan Cameron [this message]
2024-01-31 7:58 ` Nuno Sá
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=20240127155655.6495b465@jic23-huawei \
--to=jic23@kernel.org \
--cc=denis.ciocca@st.com \
--cc=devnull+nuno.sa.analog.com@kernel.org \
--cc=lars@metafoo.de \
--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