From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Taha Ed-Dafili <0rayn.dev@gmail.com>
Cc: jic23@kernel.org, lars@metafoo.de, Michael.Hennerich@analog.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
skhan@linuxfoundation.org, linux@analog.com,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/6] iio: dac: ad5504: introduce local lock to protect state and spi transfers
Date: Tue, 18 Aug 2026 09:12:16 +0300 [thread overview]
Message-ID: <aoP3wFuQBYJfEo8D@ashevche-desk.local> (raw)
In-Reply-To: <20260817211118.21833-5-0rayn.dev@gmail.com>
On Mon, Aug 17, 2026 at 05:11:13PM -0400, Taha Ed-Dafili wrote:
> The AD5504 driver currently lacks locking, exposing it to several
> multi-threading race conditions:
> 1. The shared DMA-safe SPI transfer buffers (st->data) can be
> corrupted if multiple threads trigger read_raw or write_raw
> simultaneously.
> 2. The ad5504_write_dac_powerdown() routine executes a sequence of
> back-to-back SPI writes (a CTRL register update followed by a
> mandatory NOOP). This entire sequence must be atomic.
> 3. Internal state variables like pwr_down_mask and pwr_down_mode
> can be read and modified concurrently.
>
> Introduce a mutex in the ad5504_state structure and initialize it via
> devm_mutex_init() in probe. Use the modern scoped guard(mutex) macro
> at the top-level public IIO callbacks (read_raw, write_raw, and the
> powerdown attributes) to safely serialize access to the device state
> and the SPI bus.
>
> In ad5504_read_raw() and ad5504_write_raw(), guard(mutex) is scoped to
> the IIO_CHAN_INFO_RAW case only, since IIO_CHAN_INFO_SCALE merely reads
> vref_mv, which is fixed at probe time and never modified afterward and
> therefore needs no serialization. Because guard(mutex) declares a
> cleanup-scoped variable, it cannot appear directly after a case label;
> wrap the case body in a compound statement (case IIO_CHAN_INFO_RAW: {
> ... }) to give it the block scope it requires.
Was this message written with a help with AI?
...
> + case IIO_CHAN_INFO_RAW: {
> + guard(mutex)(&st->lock);
Always use blank line(s) to separate the guard()() from the rest of the code.
> if (val >= (1 << chan->scan_type.realbits) || val < 0)
> return -EINVAL;
...
> struct ad5504_state *st = iio_priv(indio_dev);
>
> + guard(mutex)(&st->lock);
This is even stronger as we also require the blank line before return.
> return st->pwr_down_mode;
...
And so on...
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-08-18 6:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 21:11 [PATCH v4 0/6] iio: dac: ad5504: bindings, cleanups, locking, and scale fixes Taha Ed-Dafili
2026-08-17 21:11 ` [PATCH v4 1/6] dt-bindings: iio: dac: ad5504: add output-range and missing gpios Taha Ed-Dafili
2026-08-17 21:11 ` [PATCH v4 2/6] iio: dac: ad5504: Align headers with IWYU principle Taha Ed-Dafili
2026-08-17 21:24 ` sashiko-bot
2026-08-18 4:43 ` Andy Shevchenko
2026-08-17 21:11 ` [PATCH v4 3/6] iio: dac: ad5504: remove legacy platform data support Taha Ed-Dafili
2026-08-17 21:23 ` sashiko-bot
2026-08-18 4:45 ` Andy Shevchenko
2026-08-17 21:11 ` [PATCH v4 4/6] iio: dac: ad5504: introduce local lock to protect state and spi transfers Taha Ed-Dafili
2026-08-18 6:12 ` Andy Shevchenko [this message]
2026-08-17 21:11 ` [PATCH v4 5/6] iio: dac: ad5504: strictly separate ACPI and DT probe paths Taha Ed-Dafili
2026-08-17 21:21 ` sashiko-bot
2026-08-18 6:26 ` Andy Shevchenko
2026-08-17 21:11 ` [PATCH v4 6/6] iio: dac: ad5504: support scale via output-range-microvolt property Taha Ed-Dafili
2026-08-18 6:30 ` Andy Shevchenko
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=aoP3wFuQBYJfEo8D@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=0rayn.dev@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@analog.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=skhan@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox