From: Lars-Peter Clausen <lars@metafoo.de>
To: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, dianders@chromium.org,
gregkh@linuxfoundation.org, naveenkrishna.ch@gmail.com
Subject: Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Date: Fri, 15 Mar 2013 22:53:10 +0100 [thread overview]
Message-ID: <51439846.9090201@metafoo.de> (raw)
In-Reply-To: <1363364801-23684-1-git-send-email-ch.naveen@samsung.com>
On 03/15/2013 05:26 PM, Naveen Krishna Chatradhi wrote:
> This patch does the following
> 1. Handle the return values of wait_for_completion_interruptible_timeout
> 2. Add spin locks to avoid race conditions during ISR.
>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> ---
> Discussion thread for this patch can be found at
> http://www.gossamer-threads.com/lists/linux/kernel/1693284?page=last
>
> I've not seen any reference to spin lock usage in IIO.
> Kindly, suggest me if there is a better way to avoid the race.
>
> Thanks,
> Naveen
> drivers/iio/adc/exynos_adc.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index ed6fdd7..4de28ae 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -91,6 +91,7 @@ struct exynos_adc {
>
> struct completion completion;
>
> + spinlock_t reg_lock;
> u32 value;
> unsigned int version;
> };
> @@ -117,7 +118,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct exynos_adc *info = iio_priv(indio_dev);
> - unsigned long timeout;
> + long timeout;
> u32 con1, con2;
>
> if (mask != IIO_CHAN_INFO_RAW)
> @@ -143,15 +144,19 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> ADC_V1_CON(info->regs));
> }
>
> + INIT_COMPLETION(info->completion);
> +
This needs to happen before you start the transfer.
> timeout = wait_for_completion_interruptible_timeout
> (&info->completion, EXYNOS_ADC_TIMEOUT);
> +
> *val = info->value;
>
> mutex_unlock(&indio_dev->mlock);
>
> if (timeout == 0)
> return -ETIMEDOUT;
> -
> + else if (timeout < 0)
> + return timeout;
> return IIO_VAL_INT;
> }
>
> @@ -159,6 +164,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> {
> struct exynos_adc *info = (struct exynos_adc *)dev_id;
>
> + spin_lock(&info->reg_lock);
> +
> /* Read value */
> info->value = readl(ADC_V1_DATX(info->regs)) &
> ADC_DATX_MASK;
> @@ -170,6 +177,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>
> complete(&info->completion);
>
> + spin_unlock(&info->reg_lock);
> +
What exactly is the spinlock protecting against here? Concurrent runs of
exynos_adc_isr? This is probably not issue in the first place.
What you want to protect against is that completion is completed between the
call to INIT_COMPLETION() and the start of a new conversion. So the sections
that need to be under the spinlock are the complete call here and the point
from INIT_COMPLETION until the transfer is started in exynos_read_raw(). Make
sure to use spin_lock_irq there.
> return IRQ_HANDLED;
> }
>
> @@ -327,6 +336,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
> else
> indio_dev->num_channels = MAX_ADC_V2_CHANNELS;
>
> + spin_lock_init(&info->reg_lock);
> ret = iio_device_register(indio_dev);
> if (ret)
> goto err_irq;
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
To: Naveen Krishna Chatradhi
<ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
naveenkrishna.ch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Date: Fri, 15 Mar 2013 22:53:10 +0100 [thread overview]
Message-ID: <51439846.9090201@metafoo.de> (raw)
In-Reply-To: <1363364801-23684-1-git-send-email-ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 03/15/2013 05:26 PM, Naveen Krishna Chatradhi wrote:
> This patch does the following
> 1. Handle the return values of wait_for_completion_interruptible_timeout
> 2. Add spin locks to avoid race conditions during ISR.
>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Cc: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
> ---
> Discussion thread for this patch can be found at
> http://www.gossamer-threads.com/lists/linux/kernel/1693284?page=last
>
> I've not seen any reference to spin lock usage in IIO.
> Kindly, suggest me if there is a better way to avoid the race.
>
> Thanks,
> Naveen
> drivers/iio/adc/exynos_adc.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index ed6fdd7..4de28ae 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -91,6 +91,7 @@ struct exynos_adc {
>
> struct completion completion;
>
> + spinlock_t reg_lock;
> u32 value;
> unsigned int version;
> };
> @@ -117,7 +118,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct exynos_adc *info = iio_priv(indio_dev);
> - unsigned long timeout;
> + long timeout;
> u32 con1, con2;
>
> if (mask != IIO_CHAN_INFO_RAW)
> @@ -143,15 +144,19 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> ADC_V1_CON(info->regs));
> }
>
> + INIT_COMPLETION(info->completion);
> +
This needs to happen before you start the transfer.
> timeout = wait_for_completion_interruptible_timeout
> (&info->completion, EXYNOS_ADC_TIMEOUT);
> +
> *val = info->value;
>
> mutex_unlock(&indio_dev->mlock);
>
> if (timeout == 0)
> return -ETIMEDOUT;
> -
> + else if (timeout < 0)
> + return timeout;
> return IIO_VAL_INT;
> }
>
> @@ -159,6 +164,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> {
> struct exynos_adc *info = (struct exynos_adc *)dev_id;
>
> + spin_lock(&info->reg_lock);
> +
> /* Read value */
> info->value = readl(ADC_V1_DATX(info->regs)) &
> ADC_DATX_MASK;
> @@ -170,6 +177,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>
> complete(&info->completion);
>
> + spin_unlock(&info->reg_lock);
> +
What exactly is the spinlock protecting against here? Concurrent runs of
exynos_adc_isr? This is probably not issue in the first place.
What you want to protect against is that completion is completed between the
call to INIT_COMPLETION() and the start of a new conversion. So the sections
that need to be under the spinlock are the complete call here and the point
from INIT_COMPLETION until the transfer is started in exynos_read_raw(). Make
sure to use spin_lock_irq there.
> return IRQ_HANDLED;
> }
>
> @@ -327,6 +336,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
> else
> indio_dev->num_channels = MAX_ADC_V2_CHANNELS;
>
> + spin_lock_init(&info->reg_lock);
> ret = iio_device_register(indio_dev);
> if (ret)
> goto err_irq;
next prev parent reply other threads:[~2013-03-15 21:50 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 16:26 [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions Naveen Krishna Chatradhi
2013-03-15 21:53 ` Lars-Peter Clausen [this message]
2013-03-15 21:53 ` Lars-Peter Clausen
2013-03-16 0:37 ` Doug Anderson
2013-03-16 14:41 ` Lars-Peter Clausen
2013-03-16 14:41 ` Lars-Peter Clausen
2013-04-03 17:06 ` Doug Anderson
2013-04-03 17:06 ` Doug Anderson
2013-04-05 8:53 ` Lars-Peter Clausen
2013-04-05 14:56 ` Doug Anderson
2013-04-05 14:56 ` Doug Anderson
2013-04-05 16:38 ` Lars-Peter Clausen
2013-04-04 3:59 ` [PATCH 14/14] temp: iio: adc: exynos_adc: Handle timeout issues Naveen Krishna Chatradhi
2013-04-04 4:09 ` Naveen Krishna Ch
2013-04-04 4:06 ` [PATCH] " Naveen Krishna Chatradhi
2013-04-04 4:06 ` Naveen Krishna Chatradhi
2013-04-13 4:36 ` Naveen Krishna Ch
2013-04-13 4:36 ` Naveen Krishna Ch
2013-04-15 16:01 ` Doug Anderson
2013-04-15 16:01 ` Doug Anderson
2013-05-02 18:01 ` [PATCH v2] " Naveen Krishna Chatradhi
2013-05-02 18:10 ` Tomasz Figa
2013-05-02 18:10 ` Tomasz Figa
2013-05-02 18:22 ` Naveen Krishna Ch
2013-05-02 18:22 ` Naveen Krishna Ch
2013-05-02 18:36 ` Tomasz Figa
2013-05-02 18:36 ` Tomasz Figa
2013-10-11 8:23 ` [PATCH v3] iio: exynos_adc: use wait_for_completion_timeout instead of interruptible Naveen Krishna Chatradhi
2013-10-11 14:30 ` Lars-Peter Clausen
2013-10-11 14:30 ` Lars-Peter Clausen
2013-10-12 6:40 ` Naveen Krishna Ch
2013-10-12 6:40 ` Naveen Krishna Ch
2013-10-15 5:15 ` [PATCH v4] " Naveen Krishna Chatradhi
2013-10-25 15:42 ` Doug Anderson
2013-10-28 5:41 ` [PATCH v5] " Naveen Krishna Chatradhi
2013-11-05 9:45 ` [PATCH v6] " Naveen Krishna Chatradhi
2013-11-10 12:48 ` Tomasz Figa
2013-11-10 12:48 ` Tomasz Figa
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=51439846.9090201@metafoo.de \
--to=lars@metafoo.de \
--cc=ch.naveen@samsung.com \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=naveenkrishna.ch@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.