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] [day] [month] [year] [list]

Message-ID: <20240814193814.78fe45cc@jic23-huawei>
Date: Wed, 14 Aug 2024 19:38:13 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: "Esteban Blanc" <eblanc@...libre.com>
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 Wed, 14 Aug 2024 15:02:42 +0200
"Esteban Blanc" <eblanc@...libre.com> wrote:

> 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.
Sure.  Bit odd to do this post processing on device but I guess it made
sense for some customers.

Jonathan

> 
> Thanks for your time and sorry for the confusion,
>