From: Jonathan Cameron <jic23@kernel.org>
To: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <linux-iio@vger.kernel.org>
Subject: Re: [PATCH] iio: dac: ad7303: replace mlock with own lock
Date: Sat, 5 Oct 2019 15:54:07 +0100 [thread overview]
Message-ID: <20191005155252.1bfa52da@archlinux> (raw)
In-Reply-To: <20190919131328.13633-1-alexandru.ardelean@analog.com>
On Thu, 19 Sep 2019 16:13:28 +0300
Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
> This change replaces indio_dev's mlock with the driver's own lock. The lock
> is mostly needed to protect state when changing the `config` & `dac_cache`
> fields. As such, the lock has been extended to covert the read of these
> fields.
This last bit would be needed if we had anywhere that needed to see a consistent
state across those two fields. I can't immediately see where that happens.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
See below.
> ---
> drivers/iio/dac/ad7303.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/dac/ad7303.c b/drivers/iio/dac/ad7303.c
> index 8de9f40226e6..f45352e80db7 100644
> --- a/drivers/iio/dac/ad7303.c
> +++ b/drivers/iio/dac/ad7303.c
> @@ -41,6 +41,7 @@ struct ad7303_state {
> struct regulator *vdd_reg;
> struct regulator *vref_reg;
>
> + struct mutex lock;
> /*
> * DMA (thus cache coherency maintenance) requires the
> * transfer buffers to live in their own cache lines.
> @@ -62,9 +63,13 @@ static ssize_t ad7303_read_dac_powerdown(struct iio_dev *indio_dev,
> uintptr_t private, const struct iio_chan_spec *chan, char *buf)
> {
> struct ad7303_state *st = iio_priv(indio_dev);
> + int val;
>
> - return sprintf(buf, "%d\n", (bool)(st->config &
> - AD7303_CFG_POWER_DOWN(chan->channel)));
> + mutex_lock(&st->lock);
> + val = (bool)(st->config & AD7303_CFG_POWER_DOWN(chan->channel));
> + mutex_unlock(&st->lock);
I think the read of st->config should be atomic anyway so you'll either
get the value before or after some concurrent write. That's true
even with the locks, so I don't htink they are needed here.
> +
> + return sprintf(buf, "%d\n", val);
> }
>
> static ssize_t ad7303_write_dac_powerdown(struct iio_dev *indio_dev,
> @@ -79,7 +84,7 @@ static ssize_t ad7303_write_dac_powerdown(struct iio_dev *indio_dev,
> if (ret)
> return ret;
>
> - mutex_lock(&indio_dev->mlock);
> + mutex_lock(&st->lock);
>
> if (pwr_down)
> st->config |= AD7303_CFG_POWER_DOWN(chan->channel);
> @@ -90,7 +95,7 @@ static ssize_t ad7303_write_dac_powerdown(struct iio_dev *indio_dev,
> * mode, so just write one of the DAC channels again */
> ad7303_write(st, chan->channel, st->dac_cache[chan->channel]);
>
> - mutex_unlock(&indio_dev->mlock);
> + mutex_unlock(&st->lock);
> return len;
> }
>
> @@ -116,7 +121,9 @@ static int ad7303_read_raw(struct iio_dev *indio_dev,
>
> switch (info) {
> case IIO_CHAN_INFO_RAW:
> + mutex_lock(&st->lock);
> *val = st->dac_cache[chan->channel];
> + mutex_unlock(&st->lock);
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SCALE:
> vref_uv = ad7303_get_vref(st, chan);
> @@ -144,11 +151,11 @@ static int ad7303_write_raw(struct iio_dev *indio_dev,
> if (val >= (1 << chan->scan_type.realbits) || val < 0)
> return -EINVAL;
>
> - mutex_lock(&indio_dev->mlock);
> + mutex_lock(&st->lock);
> ret = ad7303_write(st, chan->address, val);
> if (ret == 0)
> st->dac_cache[chan->channel] = val;
> - mutex_unlock(&indio_dev->mlock);
> + mutex_unlock(&st->lock);
> break;
> default:
> ret = -EINVAL;
> @@ -211,6 +218,8 @@ static int ad7303_probe(struct spi_device *spi)
>
> st->spi = spi;
>
> + mutex_init(&st->lock);
> +
> st->vdd_reg = devm_regulator_get(&spi->dev, "Vdd");
> if (IS_ERR(st->vdd_reg))
> return PTR_ERR(st->vdd_reg);
next prev parent reply other threads:[~2019-10-05 14:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 13:13 [PATCH] iio: dac: ad7303: replace mlock with own lock Alexandru Ardelean
2019-10-05 14:54 ` Jonathan Cameron [this message]
2019-10-07 8:26 ` [PATCH v2] " Alexandru Ardelean
2019-10-12 13:45 ` 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=20191005155252.1bfa52da@archlinux \
--to=jic23@kernel.org \
--cc=alexandru.ardelean@analog.com \
--cc=linux-iio@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).