[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiDSCvp9gBo6Oh31GghvcHmgBY1cYqq4uM_njFTTvQOcS1mbw@mail.gmail.com>
Date: Tue, 16 Apr 2024 12:39:33 +0200
From: Ricardo Ribalda <ribalda@...omium.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Martin Tuma <martin.tuma@...iteqautomotive.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Hans Verkuil <hverkuil-cisco@...all.nl>, Hugues Fruchet <hugues.fruchet@...s.st.com>,
Alain Volmat <alain.volmat@...s.st.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>, Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>, Sowjanya Komatineni <skomatineni@...dia.com>,
Luca Ceresoli <luca.ceresoli@...tlin.com>, Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Hans Verkuil <hverkuil@...all.nl>,
Sergey Kozlov <serjk@...up.ru>, Abylay Ospan <aospan@...up.ru>,
Ezequiel Garcia <ezequiel@...guardiasur.com.ar>, Dmitry Osipenko <digetx@...il.com>,
Stanimir Varbanov <stanimir.k.varbanov@...il.com>, Vikash Garodia <quic_vgarodia@...cinc.com>,
"Bryan O'Donoghue" <bryan.odonoghue@...aro.org>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>, Benjamin Mugnier <benjamin.mugnier@...s.st.com>,
Sylvain Petinot <sylvain.petinot@...s.st.com>, Jacopo Mondi <jacopo+renesas@...ndi.org>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
Niklas Söderlund <niklas.soderlund+renesas@...natech.se>,
Pavel Machek <pavel@....cz>, linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-staging@...ts.linux.dev,
linux-sunxi@...ts.linux.dev, linux-tegra@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 23/35] media: dvb-frontends: tda10048: Use the right div
Hi Dan
What about going the safe way?
--- a/drivers/media/dvb-frontends/tda10048.c
+++ b/drivers/media/dvb-frontends/tda10048.c
@@ -341,7 +341,7 @@ static int tda10048_set_wref(struct dvb_frontend
*fe, u32 sample_freq_hz,
/* t *= 2147483648 on 32bit platforms */
t *= (2048 * 1024);
t *= 1024;
- z = 7 * sample_freq_hz;
+ z = (u64)7 * sample_freq_hz;
t = div64_u64(t, z) + 5;
do_div(t, 10);
@@ -409,6 +409,7 @@ static int tda10048_set_if(struct dvb_frontend *fe, u32 bw)
struct tda10048_config *config = &state->config;
int i;
u32 if_freq_khz;
+ u64 sample_freq;
dprintk(1, "%s(bw = %d)\n", __func__, bw);
@@ -450,9 +451,10 @@ static int tda10048_set_if(struct dvb_frontend *fe, u32 bw)
dprintk(1, "- pll_pfactor = %d\n", state->pll_pfactor);
/* Calculate the sample frequency */
- state->sample_freq = state->xtal_hz * (state->pll_mfactor + 45);
- state->sample_freq /= (state->pll_nfactor + 1);
- state->sample_freq /= (state->pll_pfactor + 4);
+ sample_freq = (u64)state->xtal_hz * (state->pll_mfactor + 45);
+ do_div(sample_freq, state->pll_nfactor + 1);
+ do_div(sample_freq, state->pll_pfactor + 4);
+ state->sample_freq = sample_freq;
dprintk(1, "- sample_freq = %d\n", state->sample_freq);
/* Update the I/F */
I will add a extra patch to fix tda10048_set_if
Thanks
PS: Thanks a lot for your reviews, really appreciate! I have a v2 with
your changes, I am giving it a couple of days before re-submitting
On Tue, 16 Apr 2024 at 12:10, Dan Carpenter <dan.carpenter@...aro.org> wrote:
>
> On Mon, Apr 15, 2024 at 07:34:40PM +0000, Ricardo Ribalda wrote:
> > z does not fit in 32 bits.
> >
>
> z has to fit in 32 bits otherwise there is a different bug.
>
> > Found by cocci:
> > drivers/media/dvb-frontends/tda10048.c:345:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead.
> >
> > Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
> > ---
> > drivers/media/dvb-frontends/tda10048.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/dvb-frontends/tda10048.c b/drivers/media/dvb-frontends/tda10048.c
> > index 5d5e4e9e4422..b176e7803e5b 100644
> > --- a/drivers/media/dvb-frontends/tda10048.c
> > +++ b/drivers/media/dvb-frontends/tda10048.c
> > @@ -342,8 +342,7 @@ static int tda10048_set_wref(struct dvb_frontend *fe, u32 sample_freq_hz,
> > t *= (2048 * 1024);
> > t *= 1024;
> > z = 7 * sample_freq_hz;
>
> sample_freq_hz is a u32 so z can't be more than U32_MAX. Perhaps there
> is an integer overflow bug on this line.
>
> The sample frequency is set in tda10048_set_if().
>
> state->sample_freq = state->xtal_hz * (state->pll_mfactor + 45);
>
> ->xtal_hz is set earlier in tda10048_set_if() and it goes up to
> 16,000,000. So if ->pll_mfactor is non-zero this line will have an
> integer overflow. 16million * 46 > U32_MAX. Maybe when .clk_freq_khz
> is TDA10048_CLK_16000 then ->pll_mfactor is zero? Ugh...
>
> > - do_div(t, z);
> > - t += 5;
> > + t = div64_u64(t, z) + 5;
> > do_div(t, 10);
>
> regards,
> dan carpenter
>
--
Ricardo Ribalda
Powered by blists - more mailing lists