linux-kernel - Re: [PATCH v3 2/3] iio: adc: Initial support for AD4134

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aTGhmgsRmphZY92X@debian-BULLSEYE-live-builder-AMD64>
Date: Thu, 4 Dec 2025 11:58:34 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, jic23@...nel.org, nuno.sa@...log.com,
	dlechner@...libre.com, andy@...nel.org,
	Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, corbet@....net
Subject: Re: [PATCH v3 2/3] iio: adc: Initial support for AD4134

On 12/02, Andy Shevchenko wrote:
> On Tue, Dec 2, 2025 at 10:55 PM Marcelo Schmitt
> <marcelo.schmitt@...log.com> wrote:
> >
> > AD4134 is a 24-bit, 4-channel, simultaneous sampling, precision
> > analog-to-digital converter (ADC). The device can be managed through SPI or
> > direct control of pin logical levels (pin control mode). The AD4134 design
> > also features a dedicated bus for ADC sample data output. Though, this
> > initial driver for AD4134 only supports usual SPI connections.
> >
> > Add basic support for AD4134 that enables single-shot ADC sample read.
> 
...
> 
> Bart converted it to be an aux driver and it should work. Please, give
> a try after v6.19-rc1 is out.
> 
Ok, from yesterday's disscussion I see I should give rest framework another try.
For now, I'll rebase on top of linux-next to experiment with the new reset gpio aux device.

...
> 
> > +        * interface. Now we read data from all channels but keep only the bits
> > +        * from the requested one.
> > +        */
> > +       for (i = 0; i < ARRAY_SIZE(ad4134_chan_set); i++) {
> > +               ret = spi_write_then_read(st->spi, NULL, 0, st->rx_buf,
> > +                                         BITS_TO_BYTES(AD4134_CHAN_PRECISION_BITS));
> > +               if (ret)
> > +                       return ret;
> > +
> > +               if (i != AD4134_VREG_CH(reg))
> > +                       continue;
> > +               *val = get_unaligned_be24(st->rx_buf);
> 
> Hmm...
> 
> In this case it might be better to  use
> 
>   if (i == ...)
>     *val = ...
> 
> but it's still unclear on how many times the conditional can be true
> in the loop.

The if != ... condition was true on three iterations of the loop and false
in only one iteration. Updated to if (i == ...), the conditional is now true
only on one iteration. 
The AD4134 has a built-in feature that flags when data trasnfers don't run
enough clock cycles to read the entire data frame (i.e. the data from all 4
channels in this case).
Since this is not expected to be a time critical method for acquiring data,
I coded it to avoid that error flag. I added a comment about that for v4.

Thanks,
Marcelo