From: Jonathan Cameron <jic23@kernel.org>
To: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Cc: "Hartmut Knaack" <knaack.h@gmx.de>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Peter Meerwald-Stadler" <pmeerw@pmeerw.net>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
"Marc Titinger" <marc.titinger@baylibre.com>,
"Stefan Brüns" <stefan.bruens@rwth-aachen.de>
Subject: Re: [PATCH] iio: adc: ina2xx: Use 64-bit arithmetic instead of 32-bit
Date: Sat, 17 Feb 2018 12:38:36 +0000 [thread overview]
Message-ID: <20180217123836.61cb3b25@archlinux> (raw)
In-Reply-To: <20180213165258.GA12967@embeddedor.com>
On Tue, 13 Feb 2018 10:52:58 -0600
"Gustavo A. R. Silva" <garsilva@embeddedor.com> wrote:
> Add suffix ULL to constant 1000 in order to give the compiler complete
> information about the proper arithmetic to use. Notice that this
> constant is used in a context that expects an expression of type
> u64 (64 bits, unsigned).
>
> The expression 1000 * sampling_us is currently being evaluated
> using 32-bit arithmetic.
>
> Addresses-Coverity-ID: 1463793
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
I've been trying to figure out if this matters in reality.
i.e. whether or not sampling_us is big enough for us to need
64 bit multiplication.
It's equal to the output for the macro SAMPLING_PERIOD(c)
(int_time_vbus + int_time_vshunt) * avg
So taking max values
(8244 + 68100) * 1024 = 78176256
Then * 1000 which brings it well into the > 32bit range.
So the next question is when was this introduced.
I guess it was Stefan's recent patch but haven't checked yet...
Marc / Stephan, could you check if we are correct in thinking this is a real
bug rather than just a numerical oddity?
Thanks,
Jonathan
> ---
> drivers/iio/adc/ina2xx-adc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> index 0635a79..8649700 100644
> --- a/drivers/iio/adc/ina2xx-adc.c
> +++ b/drivers/iio/adc/ina2xx-adc.c
> @@ -810,7 +810,7 @@ static int ina2xx_capture_thread(void *data)
> * multiple times, i.e. samples are dropped.
> */
> do {
> - timespec64_add_ns(&next, 1000 * sampling_us);
> + timespec64_add_ns(&next, 1000ULL * sampling_us);
> delta = timespec64_sub(next, now);
> delay_us = div_s64(timespec64_to_ns(&delta), 1000);
> } while (delay_us <= 0);
prev parent reply other threads:[~2018-02-17 12:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 16:52 [PATCH] iio: adc: ina2xx: Use 64-bit arithmetic instead of 32-bit Gustavo A. R. Silva
2018-02-17 12:38 ` Jonathan Cameron [this message]
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=20180217123836.61cb3b25@archlinux \
--to=jic23@kernel.org \
--cc=garsilva@embeddedor.com \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.titinger@baylibre.com \
--cc=pmeerw@pmeerw.net \
--cc=stefan.bruens@rwth-aachen.de \
/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).