lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvEA4nC8-2aMHUg+iJ8qMNuQKYnmpbpK_iZMhoivOQX14G5DQ@mail.gmail.com>
Date: Tue, 7 Jan 2025 19:28:30 +0200
From: Kosta Stefanov <costa.stephanoff@...il.com>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>, Stanimir Varbanov <stanimir.k.varbanov@...il.com>, 
	Vikash Garodia <quic_vgarodia@...cinc.com>, "Bryan O'Donoghue" <bryan.odonoghue@...aro.org>, 
	Hans Verkuil <hverkuil@...all.nl>, linux-media@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v5 1/6] media: dvb-frontends: tda10048: Make the range of
 z explicit.

hi Ricardo, according to the datasheet the recommended sampling
frequency is 55 MHz (BTW, if you look at the definitions in the source
code and make the calculations that is exactly the sampling frequency
all currently supported in Linux devices are using as well).

also, I spent few minutes time to make the calculations based on the
restrains of the PLL build-in tda10048 and in theory the maximum is 69
MHz. so, if you make next revision of this patch, feel free to update
the comment accordingly, in short - recommended sampling frequency of
55 MHz, theoretical maximum of 69 MHz.

in any case, your assumption is correct and in reality is away less
than the maximum value you assumed.

Reviewed-by: Kosta Stefanov <costa.stephanoff@...il.com>

--Kosta


On Tue, Jan 7, 2025 at 12:54 PM Ricardo Ribalda <ribalda@...omium.org> wrote:
>
> We have not been able to find the relevant datahsheet, but it seems rare
> that the device will have a sampling frequency over 613MHz.
>
> Nonetheless, this patch does not introduce any change in behaviour, it
> just adds a comment to make explicit the current limit: div by 32 bits.
>
> 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 | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/tda10048.c b/drivers/media/dvb-frontends/tda10048.c
> index 3e725cdcc66b..1886f733dbbf 100644
> --- a/drivers/media/dvb-frontends/tda10048.c
> +++ b/drivers/media/dvb-frontends/tda10048.c
> @@ -328,7 +328,8 @@ static int tda10048_set_wref(struct dvb_frontend *fe, u32 sample_freq_hz,
>                              u32 bw)
>  {
>         struct tda10048_state *state = fe->demodulator_priv;
> -       u64 t, z;
> +       u32 z;
> +       u64 t;
>
>         dprintk(1, "%s()\n", __func__);
>
> @@ -341,6 +342,7 @@ static int tda10048_set_wref(struct dvb_frontend *fe, u32 sample_freq_hz,
>         /* t *= 2147483648 on 32bit platforms */
>         t *= (2048 * 1024);
>         t *= 1024;
> +       /* Sample frequency is under 613MHz */
>         z = 7 * sample_freq_hz;
>         do_div(t, z);
>         t += 5;
>
> --
> 2.47.1.613.gc27f4b7a9f-goog
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ