linux-kernel - Re: [PATCH] iio: ad5933: Correct settling cycles encoding per datasheet

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: <CAKUZ0z+1JZs3ky3Yo4FNev8fow4bNvH_089=PvwEd-Rpvpj6Xg@mail.gmail.com>
Date: Sat, 19 Apr 2025 21:12:49 -0400
From: Gabriel Shahrouzi <gshahrouzi@...il.com>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: gregkh@...uxfoundation.org, jic23@...nel.org, lars@...afoo.de, 
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-staging@...ts.linux.dev, Michael.Hennerich@...log.com, 
	skhan@...uxfoundation.org, kernelmentees@...ts.linuxfoundation.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH] iio: ad5933: Correct settling cycles encoding per datasheet

On Sat, Apr 19, 2025 at 8:47 PM Marcelo Schmitt
<marcelo.schmitt1@...il.com> wrote:
>
> ...
> > > > @@ -411,14 +417,15 @@ static ssize_t ad5933_store(struct device *dev,
> > > >               ret = ad5933_cmd(st, 0);
> > > >               break;
> > > >       case AD5933_OUT_SETTLING_CYCLES:
> > > > -             val = clamp(val, (u16)0, (u16)0x7FF);
> > > > +             val = clamp(val, (u16)0, (u16)AD5933_MAX_SETTLING_CYCLES);
> > > >               st->settling_cycles = val;
> > > >
> > > > -             /* 2x, 4x handling, see datasheet */
> > > > +             /* Encode value for register: D10..D0 */
> > > > +             /* Datasheet Table 13: If cycles > 1022 -> val/4, set bits D10=1, D9=1 */
> > > >               if (val > 1022)
> > > > -                     val = (val >> 2) | (3 << 9);
> > > > -             else if (val > 511)
> > > > -                     val = (val >> 1) | BIT(9);
> > > > +                     val = (val >> 2) | AD5933_SETTLE_MUL_4X;
> > > then this would become something like
> > >
> > >                 reg_data &= ~AD5933_SETTLE_MUL_MSK;
> > >                 reg_data |= FIELD_PREP(AD5933_SETTLE_MUL_MSK, AD5933_SETTLE_MUL_4X);
> > >                 reg_data &= ~AD5933_SETTLING_TIME_CYCLES_MSK;
> > >                 reg_data |= FIELD_PREP(AD5933_SETTLING_TIME_CYCLES_MSK, val >> 2);
> > I currently have:
> >                         val >>= 2;
> >                         val |= FIELD_PREP(AD5933_SETTLING_MULTIPLIER_MASK,
> >                                         AD5933_SETTLING_MULTIPLIER_VAL_X4);
> > which assumes val only has bits within a certain range which I believe
> > is the case here but not completely sure. Would it be better to clear
> > the bits regardless and then apply said operations?
> Nah, since val is being clamped to max settling time value, I think this is good.
Got it.
>
> > > ...
> > >
> > > Though, I guess it would then be preferable to use masks and bitfield macros for
> > > all other places where we handle register data in ad5933 driver. Probably
> > > something for a different patch (if worth it).
> > I separated the original fix from the refactoring so the patches stay
> > modular. I can apply the use of masks and bitfield macros for other
> > register data. Should the refactoring be all in one patch or spread
> > across multiple?
>
> I believe all mask/bitfield refactoring can be done in one patch.
Sounds good.