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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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@intel.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