From: Lars-Peter Clausen <lars@metafoo.de>
To: Doug Anderson <dianders@chromium.org>
Cc: Naveen Krishna Chatradhi <ch.naveen@samsung.com>,
linux-iio <linux-iio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-samsung-soc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Naveen Krishna <naveenkrishna.ch@gmail.com>
Subject: Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Date: Sat, 16 Mar 2013 15:41:30 +0100 [thread overview]
Message-ID: <5144849A.8050907@metafoo.de> (raw)
In-Reply-To: <CAD=FV=V+-DwCjGoookySCazazBBYOoRO+=G5Q_WXAw+SrXNc-A@mail.gmail.com>
On 03/16/2013 01:37 AM, Doug Anderson wrote:
> On Fri, Mar 15, 2013 at 2:53 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> 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.
>
> ...and at that point I _think_ you won't also need the mutex.
>
> A reasonable way to test to see if you've got this all correct would be to:
>
> * Start two processes that are reading from different ADCs that will
> report very different values (maybe add a device tree node for adc1 or
> adc7 and use those since they're not really connected to
> thermistors?).
>
> * Have your two processes read as fast as they can. This could just
> be "while true; do cat /sys/class/hwmon/hwmon0/device/temp1_input;
> done"
>
> * Decrease your timeout and maybe(?) sprinkle some random udelays in
> the irq handler so that the timeouts happen sometimes but not others.
>
> * Periodically cancel one of the readers with Ctrl-C
>
> If all is working well then you should always get back the right value
> from the right reader (and get no crashes).
>
I think you still need the mutex for serialization, otherwise the requests
would just cancel each other out. Btw. what happens if you start a conversion
while another is still in progress? Is it possible to abort a conversion?
- Lars
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Naveen Krishna Chatradhi
<ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
linux-iio <linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Naveen Krishna
<naveenkrishna.ch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Date: Sat, 16 Mar 2013 15:41:30 +0100 [thread overview]
Message-ID: <5144849A.8050907@metafoo.de> (raw)
In-Reply-To: <CAD=FV=V+-DwCjGoookySCazazBBYOoRO+=G5Q_WXAw+SrXNc-A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/16/2013 01:37 AM, Doug Anderson wrote:
> On Fri, Mar 15, 2013 at 2:53 PM, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> wrote:
>> 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.
>
> ...and at that point I _think_ you won't also need the mutex.
>
> A reasonable way to test to see if you've got this all correct would be to:
>
> * Start two processes that are reading from different ADCs that will
> report very different values (maybe add a device tree node for adc1 or
> adc7 and use those since they're not really connected to
> thermistors?).
>
> * Have your two processes read as fast as they can. This could just
> be "while true; do cat /sys/class/hwmon/hwmon0/device/temp1_input;
> done"
>
> * Decrease your timeout and maybe(?) sprinkle some random udelays in
> the irq handler so that the timeouts happen sometimes but not others.
>
> * Periodically cancel one of the readers with Ctrl-C
>
> If all is working well then you should always get back the right value
> from the right reader (and get no crashes).
>
I think you still need the mutex for serialization, otherwise the requests
would just cancel each other out. Btw. what happens if you start a conversion
while another is still in progress? Is it possible to abort a conversion?
- Lars
next prev parent reply other threads:[~2013-03-16 14:39 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
2013-03-15 21:53 ` Lars-Peter Clausen
2013-03-16 0:37 ` Doug Anderson
2013-03-16 14:41 ` Lars-Peter Clausen [this message]
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=5144849A.8050907@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.