Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 29 Oct 2022 13:11:19 +0100
From:   Jonathan Cameron <jic23@kernel.org>
To:     "Sa, Nuno" <Nuno.Sa@analog.com>
Cc:     Deepak R Varma <drv@mailo.com>,
        "outreachy@lists.linux.dev" <outreachy@lists.linux.dev>,
        Lars-Peter Clausen <lars@metafoo.de>,
        "Hennerich, Michael" <Michael.Hennerich@analog.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] staging: iio: frequency: ad9834: Use div64_ul
 instead of do_div
Message-ID: <20221029131119.2f000985@jic23-huawei>
In-Reply-To: <SJ0PR03MB677828AF20AAF0FC1A167C3C99329@SJ0PR03MB6778.namprd03.prod.outlook.com>
References: <Y1r/RAk83Csk2L3E@ubunlion>
        <SJ0PR03MB677828AF20AAF0FC1A167C3C99329@SJ0PR03MB6778.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 28 Oct 2022 10:14:48 +0000
"Sa, Nuno" <Nuno.Sa@analog.com> wrote:

> > -----Original Message-----
> > From: Deepak R Varma <drv@mailo.com>
> > Sent: Friday, October 28, 2022 12:00 AM
> > To: outreachy@lists.linux.dev; Lars-Peter Clausen <lars@metafoo.de>;
> > Hennerich, Michael <Michael.Hennerich@analog.com>; Jonathan Cameron
> > <jic23@kernel.org>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>;
> > linux-iio@vger.kernel.org; linux-staging@lists.linux.dev; linux-
> > kernel@vger.kernel.org
> > Subject: [PATCH v2] staging: iio: frequency: ad9834: Use div64_ul inste=
ad of
> > do_div
> >=20
> > [External]
> >=20
> > do_div() does a 64-by-32 division. Here the divisor is an unsigned long
> > which on some platforms is 64 bit wide. So use div64_ul instead of do_d=
iv
> > to avoid a possible truncation. Issue identified using the
> > coccicheck tool.
> >=20
> > Signed-off-by: Deepak R Varma <drv@mailo.com>
> > --- =20
>=20
> Clearly, I should have looked better and only reply to this one:
>=20
> Reviewed-by: Nuno S=C3=A1 <nuno.sa@analog.com>

As per the email Greg linked to, please take a close look at the surround c=
ode
and include analysis of whether the value can actually be greater than 32 b=
its.
Note that in most cases that would actually mean the code was broken on 32 =
bit
platforms.