From: Marek Vasut <marex@denx.de>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: jic23@kernel.org, festevam@gmail.com,
kristina.martsenko@gmail.com, knaack.h@gmx.de,
kernel@pengutronix.de, pawel.moll@arm.com,
ijc+devicetree@hellion.org.uk, robh+dt@kernel.org,
galak@codeaurora.org, mark.rutland@arm.com,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] iio: mxs-lradc: check ranges of ts properties
Date: Tue, 23 Dec 2014 14:37:22 +0100 [thread overview]
Message-ID: <201412231437.22809.marex@denx.de> (raw)
In-Reply-To: <1419250476-2393-3-git-send-email-stefan.wahren@i2se.com>
On Monday, December 22, 2014 at 01:14:36 PM, Stefan Wahren wrote:
> The devicetree binding for mxs-lradc defines ranges for the
> touchscreen properties. In order to avoid unexpected behavior like
> division by zero, we better check these ranges during probe and
> abort in error case.
>
> Additionally this patch adds an important note from the reference
> manual about the range of sample delay.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/staging/iio/adc/mxs-lradc.c | 44
> +++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 10
> deletions(-)
>
> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
> b/drivers/staging/iio/adc/mxs-lradc.c index f053535..990e945 100644
> --- a/drivers/staging/iio/adc/mxs-lradc.c
> +++ b/drivers/staging/iio/adc/mxs-lradc.c
> @@ -436,7 +436,13 @@ static void mxs_lradc_setup_ts_channel(struct
> mxs_lradc *lradc, unsigned ch) */
> mxs_lradc_reg_clear(lradc, LRADC_CH_VALUE_MASK, LRADC_CH(ch));
>
> - /* prepare the delay/loop unit according to the oversampling count */
> + /* prepare the delay/loop unit according to the oversampling count
Very minor coding style flub in this comment above. Multi-line comments should
start with /* and a newline after that ;-)
> + * from the datasheet:
> + * "The DELAY fields in HW_LRADC_DELAY0, HW_LRADC_DELAY1,
> + * HW_LRADC_DELAY2, and HW_LRADC_DELAY3 must be non-zero; otherwise,
> + * the LRADC will not trigger the delay group."
> + */
> mxs_lradc_reg_wrt(lradc, LRADC_DELAY_TRIGGER(1 << ch) |
> LRADC_DELAY_TRIGGER_DELAYS(0) |
> LRADC_DELAY_LOOP(lradc->over_sample_cnt - 1) |
> @@ -1495,20 +1501,38 @@ static int mxs_lradc_probe_touchscreen(struct
> mxs_lradc *lradc, return -EINVAL;
> }
>
> - lradc->over_sample_cnt = 4;
> - ret = of_property_read_u32(lradc_node, "fsl,ave-ctrl", &adapt);
> - if (ret == 0)
> + if (of_property_read_u32(lradc_node, "fsl,ave-ctrl", &adapt)) {
> + lradc->over_sample_cnt = 4;
> + } else {
> + if (adapt < 1 || adapt > 32) {
This is just an idea, but do we not have some kind of a
"of_property_read_u32_range()" thingie, which would include this kind of range
checking ? Would it be worth implementing such thing ? What do you think
please ?
[...]
Otherwise,
Reviewed-by: Marek Vasut <marex@denx.de>
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
kristina.martsenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
knaack.h-Mmb7MZpHnFY@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] iio: mxs-lradc: check ranges of ts properties
Date: Tue, 23 Dec 2014 14:37:22 +0100 [thread overview]
Message-ID: <201412231437.22809.marex@denx.de> (raw)
In-Reply-To: <1419250476-2393-3-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
On Monday, December 22, 2014 at 01:14:36 PM, Stefan Wahren wrote:
> The devicetree binding for mxs-lradc defines ranges for the
> touchscreen properties. In order to avoid unexpected behavior like
> division by zero, we better check these ranges during probe and
> abort in error case.
>
> Additionally this patch adds an important note from the reference
> manual about the range of sample delay.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
> drivers/staging/iio/adc/mxs-lradc.c | 44
> +++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 10
> deletions(-)
>
> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
> b/drivers/staging/iio/adc/mxs-lradc.c index f053535..990e945 100644
> --- a/drivers/staging/iio/adc/mxs-lradc.c
> +++ b/drivers/staging/iio/adc/mxs-lradc.c
> @@ -436,7 +436,13 @@ static void mxs_lradc_setup_ts_channel(struct
> mxs_lradc *lradc, unsigned ch) */
> mxs_lradc_reg_clear(lradc, LRADC_CH_VALUE_MASK, LRADC_CH(ch));
>
> - /* prepare the delay/loop unit according to the oversampling count */
> + /* prepare the delay/loop unit according to the oversampling count
Very minor coding style flub in this comment above. Multi-line comments should
start with /* and a newline after that ;-)
> + * from the datasheet:
> + * "The DELAY fields in HW_LRADC_DELAY0, HW_LRADC_DELAY1,
> + * HW_LRADC_DELAY2, and HW_LRADC_DELAY3 must be non-zero; otherwise,
> + * the LRADC will not trigger the delay group."
> + */
> mxs_lradc_reg_wrt(lradc, LRADC_DELAY_TRIGGER(1 << ch) |
> LRADC_DELAY_TRIGGER_DELAYS(0) |
> LRADC_DELAY_LOOP(lradc->over_sample_cnt - 1) |
> @@ -1495,20 +1501,38 @@ static int mxs_lradc_probe_touchscreen(struct
> mxs_lradc *lradc, return -EINVAL;
> }
>
> - lradc->over_sample_cnt = 4;
> - ret = of_property_read_u32(lradc_node, "fsl,ave-ctrl", &adapt);
> - if (ret == 0)
> + if (of_property_read_u32(lradc_node, "fsl,ave-ctrl", &adapt)) {
> + lradc->over_sample_cnt = 4;
> + } else {
> + if (adapt < 1 || adapt > 32) {
This is just an idea, but do we not have some kind of a
"of_property_read_u32_range()" thingie, which would include this kind of range
checking ? Would it be worth implementing such thing ? What do you think
please ?
[...]
Otherwise,
Reviewed-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
next prev parent reply other threads:[~2014-12-23 13:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 12:14 [PATCH 0/2] iio: mxs-lradc: check ranges of ts properties Stefan Wahren
2014-12-22 12:14 ` Stefan Wahren
2014-12-22 12:14 ` [PATCH 1/2] DT: mxs-lradc: fix " Stefan Wahren
2014-12-22 12:14 ` Stefan Wahren
2014-12-22 12:14 ` [PATCH 2/2] iio: mxs-lradc: check " Stefan Wahren
2014-12-22 12:14 ` Stefan Wahren
2014-12-23 13:37 ` Marek Vasut [this message]
2014-12-23 13:37 ` Marek Vasut
2014-12-23 22:45 ` Stefan Wahren
2014-12-23 22:45 ` Stefan Wahren
2014-12-24 0:35 ` Marek Vasut
2014-12-24 0:35 ` Marek Vasut
2014-12-26 9:22 ` Jonathan Cameron
2014-12-26 9:22 ` Jonathan Cameron
2014-12-26 9:23 ` Jonathan Cameron
2014-12-26 9:23 ` Jonathan Cameron
2014-12-26 20:50 ` Stefan Wahren
2014-12-26 20:50 ` Stefan Wahren
2014-12-26 21:57 ` Jonathan Cameron
2014-12-26 21:57 ` 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=201412231437.22809.marex@denx.de \
--to=marex@denx.de \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jic23@kernel.org \
--cc=kernel@pengutronix.de \
--cc=knaack.h@gmx.de \
--cc=kristina.martsenko@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=stefan.wahren@i2se.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.