RE: [PATCH] iio: gts-helper: Fix division loop

[David Laight]

From: Matti Vaittinen
> Sent: 22 January 2024 06:51
> 
> On 1/19/24 13:56, Subhajit Ghosh wrote:
> > On 8/1/24 02:52, Jonathan Cameron wrote:
> >> On Thu, 4 Jan 2024 11:34:28 +0200
> >> Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
> >>
> >>> The loop based 64bit division may run for a long time when dividend is a
> >>> lot bigger than the divider. Replace the division loop by the
> >>> div64_u64() which implementation may be significantly faster.
> >>>
> >>> Signed-off-by: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
> >>> Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers")
> >>
> >> Hmm. Fix or not perf improvement?  I'm going to take the middle ground
> >> and leave the fixes tag, but not rush this in.
> >>
> >> So applied to the togreg branch of iio.git and for now just pushed out
> >> as testing for 0-day etc to take a look before I rebase that tree after
> >> rc1.
> >>
> >>
> >>
> >>> ---
> >>>
> >>> I've implemented also a fixup series for supporting rounding of
> >>> gains/scales:
> >>>
> https://lore.kernel.org/lkml/37d3aa193e69577353d314e94463a08d488ddd8d.1701780964.git.mazziesaccount@gm
> ail.com/
> >>>
> >>> That series does also remove the offending loop.
> >>>
> >>> We don't currently have any in-tree users of GTS helpers which would
> >>> need the rounding support so pushing the rounding is not urgent (and I
> >>> haven't heard of Subjahit whose driver required the rounding). Hence, we
> >>> may want to only take this loop fix in for now (?) and reconsider
> >>> rounding when someone need that.

Why did I look as this crappy code :-)
I think the change breaks the rounding.
For 'normal' values I think you just want:
	return 1 + (max - 1)/scale.

The 'avoid overflow' test isn't needed if you subtract 1 from max.
(Rather than return (max + scale - 1)/scale; where the add can overflow.
But you do need something to return 1 (or error) if max is zero.

	David

> >>>
> >>> Jonathan, what's your take on this?
> >> Agreed - let us wait for the rounding to have a user, but makes sense
> >> to tidy this corner up in the meantime.
> >>
> >> Thanks,
> >>
> >> Jonathan
> >>
> >>>
> >>>   drivers/iio/industrialio-gts-helper.c | 5 ++---
> >>>   1 file changed, 2 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/industrialio-gts-helper.c
> >>> b/drivers/iio/industrialio-gts-helper.c
> >>> index 7653261d2dc2..abcab2d38589 100644
> >>> --- a/drivers/iio/industrialio-gts-helper.c
> >>> +++ b/drivers/iio/industrialio-gts-helper.c
> >>> @@ -34,7 +34,7 @@
> >>>   static int iio_gts_get_gain(const u64 max, const u64 scale)
> >>>   {
> >>>       u64 full = max;
> >>> -    int tmp = 1;
> >>> +    int tmp = 0;
> >>>       if (scale > full || !scale)
> >>>           return -EINVAL;
> >>> @@ -48,8 +48,7 @@ static int iio_gts_get_gain(const u64 max, const
> >>> u64 scale)
> >>>           tmp++;
> >>>       }
> >>> -    while (full > scale * (u64)tmp)
> >>> -        tmp++;
> >>> +    tmp += div64_u64(full, scale);
> >>>       return tmp;
> >>>   }
> >>>
> >>> base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
> >>
> >>
> > Hi Matti,
> >
> > Your fix works beautifully with the latest version of apds9306 driver
> > which I am working on.
> > All available scale values can be set without any errors. Thank you.
> 
> Thanks for testing Subhajit! Just to ensure we have no miscommunication
> - did you test just this division fix, or the rounding fix here:
> https://lore.kernel.org/lkml/37d3aa193e69577353d314e94463a08d488ddd8d.1701780964.git.mazziesaccount@gm
> ail.com/
> 
> > Moving to a new city with a new full time job with the assumption of
> > getting more time
> > for my list of opensource projects and contributions proved to be
> > utterly wrong!
> 
> Well, I can't blame you :) Being in a new work at new city sounds like
> you have a lot on your plate right now. Give it half a year and things
> will stabilize though :) Oh, and falsely assuming that "when XXX, I will
> have the time to do YYY" - been there done that :)
> 
> Good luck on the new work and city!
> 
> Yours,
> 	-- Matti
> 
> --
> Matti Vaittinen
> Linux kernel developer at ROHM Semiconductors
> Oulu Finland
> 
> ~~ When things go utterly wrong vim users can always type :help! ~~
> 

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)