From: Jonathan Cameron <jic23@kernel.org>
To: Mircea Caprioru <mircea.caprioru@analog.com>
Cc: <Michael.Hennerich@analog.com>, <alexandru.ardelean@analog.com>,
<lars@metafoo.de>, <gregkh@linuxfoundation.org>,
<linux-kernel@vger.kernel.org>, <linux-iio@vger.kernel.org>,
Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Subject: Re: [PATCH 5/5] iio: adc: rockchip_saradc: Replace indio_dev->mlock with own device lock
Date: Tue, 29 Sep 2020 17:23:29 +0100 [thread overview]
Message-ID: <20200929172329.778ab2c6@archlinux> (raw)
In-Reply-To: <20200928131333.36646-5-mircea.caprioru@analog.com>
On Mon, 28 Sep 2020 16:13:33 +0300
Mircea Caprioru <mircea.caprioru@analog.com> wrote:
> From: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
>
> As part of the general cleanup of indio_dev->mlock, this change replaces
> it with a local lock on the device's state structure.
>
> This is part of a bigger cleanup.
> Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
>
> Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
> Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com>
Another driver with buffered support which means we need to think
harder about what is going on with these locks.
> ---
> drivers/iio/adc/rockchip_saradc.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c
> index 1f3d7d639d37..80084c526cc6 100644
> --- a/drivers/iio/adc/rockchip_saradc.c
> +++ b/drivers/iio/adc/rockchip_saradc.c
> @@ -53,6 +53,15 @@ struct rockchip_saradc {
> const struct rockchip_saradc_data *data;
> u16 last_val;
> const struct iio_chan_spec *last_chan;
> + /*
> + * Lock to protect the device state during a potential concurrent
> + * read access from userspace. Reading a raw value requires a sequence
> + * of register writes, then a wait for a completion callback,
> + * and finally a register read, during which userspace could issue
> + * another read request. This lock protects a read access from
> + * ocurring before another one has finished.
> + */
> + struct mutex lock;
> };
>
> static void rockchip_saradc_power_down(struct rockchip_saradc *info)
> @@ -92,17 +101,17 @@ static int rockchip_saradc_read_raw(struct iio_dev *indio_dev,
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> - mutex_lock(&indio_dev->mlock);
> + mutex_lock(&info->lock);
Probably a case for iio_device_claim_direct_mode() as I doubt we want
to enter buffered mode when halfway through this.
>
> ret = rockchip_saradc_conversion(info, chan);
> if (ret) {
> rockchip_saradc_power_down(info);
> - mutex_unlock(&indio_dev->mlock);
> + mutex_unlock(&info->lock);
> return ret;
> }
>
> *val = info->last_val;
> - mutex_unlock(&indio_dev->mlock);
> + mutex_unlock(&info->lock);
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SCALE:
> ret = regulator_get_voltage(info->vref);
> @@ -254,7 +263,7 @@ static irqreturn_t rockchip_saradc_trigger_handler(int irq, void *p)
> int ret;
> int i, j = 0;
>
> - mutex_lock(&i_dev->mlock);
> + mutex_lock(&info->lock);
Hmm. I wonder what this was meant to protect?
I can't see why we need it if we are claiming direct mode correctly above.
>
> for_each_set_bit(i, i_dev->active_scan_mask, i_dev->masklength) {
> const struct iio_chan_spec *chan = &i_dev->channels[i];
> @@ -271,7 +280,7 @@ static irqreturn_t rockchip_saradc_trigger_handler(int irq, void *p)
>
> iio_push_to_buffers_with_timestamp(i_dev, &data, iio_get_time_ns(i_dev));
> out:
> - mutex_unlock(&i_dev->mlock);
> + mutex_unlock(&info->lock);
>
> iio_trigger_notify_done(i_dev->trig);
>
> @@ -332,6 +341,8 @@ static int rockchip_saradc_probe(struct platform_device *pdev)
> info->reset = NULL;
> }
>
> + mutex_init(&info->lock);
> +
> init_completion(&info->completion);
>
> irq = platform_get_irq(pdev, 0);
next prev parent reply other threads:[~2020-09-29 16:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 13:13 [PATCH 1/5] iio: adc: spear_adc: Replace indio_dev->mlock with own device lock Mircea Caprioru
2020-09-28 13:13 ` [PATCH 2/5] iio: adc: palmas_gpadc: " Mircea Caprioru
2021-02-21 16:38 ` Jonathan Cameron
2020-09-28 13:13 ` [PATCH 3/5] iio: adc: npcm_adc: " Mircea Caprioru
2021-02-21 16:39 ` Jonathan Cameron
2020-09-28 13:13 ` [PATCH 4/5] iio: adc: vf610_adc: " Mircea Caprioru
2020-09-29 16:14 ` Jonathan Cameron
2020-09-30 5:57 ` Alexandru Ardelean
2020-09-30 10:49 ` Jonathan Cameron
2020-09-28 13:13 ` [PATCH 5/5] iio: adc: rockchip_saradc: " Mircea Caprioru
2020-09-29 16:23 ` Jonathan Cameron [this message]
2021-02-21 16:37 ` [PATCH 1/5] iio: adc: spear_adc: " 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=20200929172329.778ab2c6@archlinux \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=alexandru.ardelean@analog.com \
--cc=gregkh@linuxfoundation.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mircea.caprioru@analog.com \
--cc=sergiu.cuciurean@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).