linux-kernel - Re: [PATCH] staging: iio: impedance-analyzer: ad5933: use div64_ul() instead of do

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] [day] [month] [year] [list]

Message-ID: <aXJmYAZ-8KkXCFI9@smile.fi.intel.com>
Date: Thu, 22 Jan 2026 20:03:12 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Archit Anant <architanant5@...il.com>
Cc: jic23@...nel.org, lars@...afoo.de, Michael.Hennerich@...log.com,
	gregkh@...uxfoundation.org, dlechner@...libre.com,
	nuno.sa@...log.com, andy@...nel.org, linux-iio@...r.kernel.org,
	linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: iio: impedance-analyzer: ad5933: use div64_ul()
 instead of do_div()

On Thu, Jan 22, 2026 at 10:27:52PM +0530, Archit Anant wrote:
> (Resending to the list, apologies for the private reply earlier.)

First of all, do no top post!

> Thanks for the review and the detailed math breakdown.
> 
> I agree that `(freq * BIT_ULL(29)) / mclk` is algebraically superior and
> improves precision.
> 
> However, regarding your concern about the original code:
> > "why the original code drops precision, was it deliberate?"
> 
> Since I do not have the AD5933 hardware to test if the register expects the
> truncated value from `(mclk / 4)`, I am hesitant to change the logic in
> this patch.
> 
> Would you prefer I:
> 1. Stick to a purely mechanical change (keep the logic equivalent, just use
> `div64_ul` and `BIT_ULL(27)` for readability)?
> 2. Or proceed with the `BIT_ULL(29)` simplification assuming the precision
> loss was unintentional?

I definitely prefer #2. That's why I plead to AD people to confirm.

> I'm leaning towards #1 for safety, but happy to do #2 if the maintainers
> (Lars/Michael) think it's safe.

> On Thu, Jan 22, 2026 at 8:45 PM Andy Shevchenko <andriy.shevchenko@...el.com>
> wrote:
> 
> > On Thu, Jan 22, 2026 at 05:12:42PM +0200, Andy Shevchenko wrote:
> > > On Thu, Jan 22, 2026 at 08:26:33PM +0530, Archit Anant wrote:
> >
> > ...
> >
> > > > -   freqreg = (u64)freq * (u64)(1 << 27);
> > > > -   do_div(freqreg, st->mclk_hz / 4);
> > > > +   freqreg = div64_ul((u64)freq * (u64)(1 << 27),
> > > > +                      st->mclk_hz / 4);
> > >
> > > It can be one line to begin with.
> > > Then drop that ugly castings and explicit big shifts.
> > >
> > >       freqreg = div64_ul(BIT_ULL(27) * freq, st->mclk_hz / 4);
> > >
> > > Now you can see That 4 is only 2 bits, so this can be written in
> > > simpler way:
> > >
> > >       freqreg = div64_ul(BIT_ULL(29) * freq, st->mclk_hz);
> > >
> > > which may give a better precision at the end of the day.
> >
> > It also might be worth to add a comment on top to explain (with given
> > context
> > I don't know if there is already one on top of the function, though).
> >
> > And I think we want AD people to comment on this and maybe explain better
> > the calculations done (and why the original code drops precision, was it
> > deliberate?).

-- 
With Best Regards,
Andy Shevchenko