linux-kernel - Re: [PATCH 4/4] iio: adc: ad7768-1: add support for ADAQ776x-1 ADC Family

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: <CAHp75VepJCCk9zJ6g9tO__FP5jq4EiCtf4mwYGuFf9BO3auJYg@mail.gmail.com>
Date: Tue, 19 Aug 2025 23:09:51 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: Jonathan Santos <Jonathan.Santos@...log.com>, linux-iio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Michael.Hennerich@...log.com, jic23@...nel.org, dlechner@...libre.com, 
	nuno.sa@...log.com, andy@...nel.org, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, jonath4nns@...il.com
Subject: Re: [PATCH 4/4] iio: adc: ad7768-1: add support for ADAQ776x-1 ADC Family

On Tue, Aug 19, 2025 at 10:14 PM Marcelo Schmitt
<marcelo.schmitt1@...il.com> wrote:
> On 08/12, Jonathan Santos wrote:
> > Add support for ADAQ7767/68/69-1 series, which includes PGIA and

...

> > +static int ad7768_calc_pga_gain(struct ad7768_state *st, int gain_int,
> > +                             int gain_fract, int precision)
> > +{
> > +     u64 gain_nano, tmp;
> > +     int gain_idx;
> > +
> > +     precision--;
> This is odd out of context.
> Also, it only applies to ADCs that provide output codes in two's complement
> format. See comment below.
>
>
> > +     gain_nano = gain_int * NANO + gain_fract;
> > +     if (gain_nano < 0 || gain_nano > ADAQ776X_GAIN_MAX_NANO)
> I've seen some build tools complain about comparisons like gain_nano < 0 with
> gain_nano being u64. Since that's unsigned, it can never be < 0. And in the
> context of gain/attenuation, we know gain_nano shall never be negative.
> Would just drop the gain_nano < 0 comparison. Or maybe clamp() the value?

in_range() can be used as well.

> > +             return -EINVAL;
> > +
> > +     tmp = DIV_ROUND_CLOSEST_ULL(gain_nano << precision, NANO);
> > +     gain_nano = DIV_ROUND_CLOSEST_ULL(st->vref_uv, tmp);
> > +     if (st->chip->has_variable_aaf)
> > +             /* remove the AAF gain from the overall gain */
> > +             gain_nano = DIV_ROUND_CLOSEST_ULL(gain_nano *  MILLI,
> > +                                               ad7768_aaf_gains[st->aaf_gain]);
> > +     tmp = st->chip->num_pga_modes;
> > +     gain_idx = find_closest(gain_nano, st->chip->pga_gains, tmp);
> > +
> > +     return gain_idx;
> > +}

-- 
With Best Regards,
Andy Shevchenko