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

From: Archit Anant

Date: Wed Feb 18 2026 - 13:37:04 EST


On Wed, Feb 18, 2026 at 11:49 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> On Tue, 17 Feb 2026 22:16:19 +0530
> Archit Anant <architanant5@xxxxxxxxx> wrote:
>
> > On Tue, Feb 17, 2026 at 12:34 AM David Lechner <dlechner@xxxxxxxxxxxx> wrote:
> > > Actually, I just saw this was in staging, so I guess not breaking userspace
> > > isn't the top priority if there the other way is objectively better. I would
> > > assume that testing/measurement could show which is actually correct.
> >
> > Since I don't have the hardware to perform those measurements and confirm
> > if the precision improvement is valid or a regression, I will take the
> > conservative
> > approach for v2.
> >
> > I will send a v2 that only replaces do_div() with div64_ul() and uses
> > BIT_ULL(27), preserving the original (mclk / 4) logic to guarantee no
> > behavioral change.
> >
>
> I started writing that I didn't care either way and given the chances of
> not having to fix some ABI up on the way out of staging is near zero
> (which would break any userspace anyway) but then I took at look at the
> log. We've had a fixes for this fairly recently!
>
> Might imply Gabriel has hardware? (or a 'healthy' interest in
> reading data sheets! :)
>
> So +CC Gabriel who might have some insight.
>
> Thanks,
>
> Jonathan

Hi Jonathan,

Thanks for the lead.

Hi Gabriel,

I sent out a v2 of this patch earlier today [1] using BIT_ULL(27)
while preserving the original (mclk / 4) logic for safety.

If you have access to the hardware or documentation, I would
appreciate any insight into whether Andy's suggested simplification
to (mclk) instead of (mclk / 4) would be a valid precision improvement
or if the original truncation was intentional.

[1] https://lore.kernel.org/all/20260218125327.21467-1-architanant5@xxxxxxxxx/

--
Sincerely,
Archit Anant