linux-kernel - Re: [PATCH RFC 0/5] iio: adc: ad4030: new driver for AD4030 and similar ADCs

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: <D3FNL323ZXLQ.2D0QLACO67VTP@baylibre.com>
Date: Wed, 14 Aug 2024 15:02:42 +0200
From: "Esteban Blanc" <eblanc@...libre.com>
To: "Jonathan Cameron" <jic23@...nel.org>
Cc: "Lars-Peter Clausen" <lars@...afoo.de>, "Michael Hennerich"
 <Michael.Hennerich@...log.com>, "Rob Herring" <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 "Nuno Sa" <nuno.sa@...log.com>, <linux-iio@...r.kernel.org>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>, "David
 Lechner" <dlechner@...libre.com>
Subject: Re: [PATCH RFC 0/5] iio: adc: ad4030: new driver for AD4030 and
 similar ADCs

On Sat Jun 29, 2024 at 6:40 PM CEST, Jonathan Cameron wrote:
> On Thu, 27 Jun 2024 13:59:11 +0200
> Esteban Blanc <eblanc@...libre.com> wrote:
>
> > This is adding DT bindings and a new driver for AD4030, AD4630 and
> > AD4632 ADCs.
> > 
> > This work is being done in collaboration with Analog Devices Inc.,
> > hence they are listed as maintainers rather than me.
> > 
> > The code has been tested on a Zedboard with an EVAL-AD4030-24FMCZ,
> > an EVAL-AD4630-24FMCZ and an EVAL-AD4630-16FMCZ. As there is no eval
> > board for AD4632 the support can't be tested at the moment. The main
> > difference is the reduced throughput.
> > 
> > This series is taged as RFC because I think I'm misusing
> > IIO_CHAN_INFO_CALIB*. For CALIBBIAS the doc in sysfs-bus-iio says
> > "Hardware applied calibration offset (assumed to fix production
> > inaccuracies)" but AD4030 offset in on 24bits and I would argue that at
> > this point it's not just here to fix production inaccuracies. Same this
> > for CALIBSCALE. What IIO attributes should I use instead?
>
> Interesting.   So awkward question for you.  What's the point in applying
> a digital offset?  calibbias is normally about tweaking the Analog side.
> This just seems to be adding a value on.  I'm not sure it affects what
> can actually be captured without saturation.

True, both scale and offset applied with thoses registers can lead to
saturation.

> Maybe it has influence by changing the input range and scale for the
> block averaging filter?  I'm not sure.
>
> You can use offset for this given it's a simple linear value and not
> anything to do with calibration. It's a little awkward though as that
> is post scale rather than the other way around which is rather more
> common.
> Controls are in the form
> voltage = (raw + offset) * scale 
>
> So here
> voltage = (raw + offset_reg / (gain_reg * other scaling)) * gain_reg * otherscaling.
>
> Hence your offset is a bit fiddly to compute.

After talking to ADI engineer about this, the conclusion is that I was
wrong and this is indeed mostly for calibration. They left the range
of values quite wide in case a user wanted to use this to apply an
offset or scale to the raw value directly in order to avoid doing some
post processing later on. But the main goal is calibration.

If that's ok with you I will keep CALIBBIAS and CALIBSCALE for the next
round and remove the RFC tag.

Thanks for your time and sorry for the confusion,

-- 
Esteban "Skallwar" Blanc
BayLibre