linux-kernel - Re: [PATCH v12 07/16] iio: afe: rescale: add INT_PLUS

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: <Yd2VQkwle2+IiEAZ@shaak>
Date:   Tue, 11 Jan 2022 09:33:38 -0500
From:   Liam Beguin <liambeguin@...il.com>
To:     Peter Rosin <peda@...ntia.se>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-iio <linux-iio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v12 07/16] iio: afe: rescale: add INT_PLUS_{MICRO,NANO}
 support

On Sun, Jan 09, 2022 at 09:20:09PM +0100, Peter Rosin wrote:
> Hi!
> 
> On 2022-01-09 13:48, Andy Shevchenko wrote:
> > On Sat, Jan 8, 2022 at 10:53 PM Liam Beguin <liambeguin@...il.com> wrote:
> >>
> >> Some ADCs use IIO_VAL_INT_PLUS_{NANO,MICRO} scale types.
> >> Add support for these to allow using the iio-rescaler with them.
> > 
> > ...
> > 
> >> +               mult = scale_type == IIO_VAL_INT_PLUS_NANO ? GIGA : MEGA;
> >> +
> >> +               /*
> >> +                * For IIO_VAL_INT_PLUS_{MICRO,NANO} scale types if either *val
> >> +                * OR *val2 is negative the schan scale is negative, i.e.
> >> +                * *val = 1 and *val2 = -0.5 yields -1.5 not -0.5.
> >> +                */
> >> +               neg = *val < 0 || *val2 < 0;
> >> +
> >> +               tmp = (s64)abs(*val) * abs(rescale->numerator);
> >> +               *val = div_s64_rem(tmp, abs(rescale->denominator), &rem);
> >> +
> >> +               tmp = (s64)rem * mult + (s64)abs(*val2) * abs(rescale->numerator);
> >> +               tmp = div_s64(tmp, abs(rescale->denominator));
> > 
> > Isn't it too many repetitive abs() calls?
> > 
> > What about
> > 
> > // Create a macro and use for u16 (struct rn5t618_channel_ratios), s16
> > (struct twl4030_prescale_divider_ratios), s32 (can be reused in struct
> > rescale)
> > struct u32_fract {
> >   u32 numerator;
> >   u32 denominator;
> > };
> > // (potential reuse in struct hclge_ptp_cycle) and so on...
> > 
> >   struct u32_fract fract = {
> >     .numerator = abs(rescale->numerator),
> >     .denominator = abs(rescale->denominator),
> >   };
> > 
> > // obviously we can add a macro/inliner to abs() the fract struct and
> > return original sign
> > 
> > and reuse fract.numerator, fract.denominator?
> 
> This feels a bit excessive when the "problem" is two extra abs calls.
> I don't think the code will get any easier to read by changing
> abs(rescale->denominator) into fract.denominator and with my maintainer
> hat on, I vote for just letting the compiler exercise its CSE engine.

I agree with Peter here, and would rather keep it as is.

Liam

> Cheers,
> Peter