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: <29d79f863bd0352fa0e3fca36ba5cc007f467eff.camel@gmail.com>
Date: Fri, 02 May 2025 08:43:55 +0100
From: Nuno Sá <noname.nuno@...il.com>
To: David Lechner <dlechner@...libre.com>, Angelo Dureghello	
 <adureghello@...libre.com>, Jonathan Cameron <jic23@...nel.org>, Nuno
 Sá	 <nuno.sa@...log.com>, Andy Shevchenko
 <andy@...nel.org>, 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>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH 3/5] iio: adc: ad7606: add offset and phase calibration
 support

On Wed, 2025-04-30 at 13:33 -0500, David Lechner wrote:
> On 4/30/25 11:14 AM, David Lechner wrote:
> > On 4/30/25 10:36 AM, Nuno Sá wrote:
> > > On Tue, 2025-04-29 at 15:06 +0200, Angelo Dureghello wrote:
> > > > From: Angelo Dureghello <adureghello@...libre.com>
> > > > 
> > > > 
> 
> ...
> 
> > > > +
> > > > +	val += start_val;
> > > 
> > > Shouldn't this be val -= start_val?
> > > 
> > > I also don't think we have any strict rules in the ABI for units for these
> > > kind
> > > of interfaces so using "raw" values is easier. But FWIW, I think we could
> > > have
> > > this in mv (would naturally depend on scale) 
> > > 
> > > - Nuno Sá
> > > 
> > 
> > From testing, it seems to be working as expected for me, so I think this is
> > correct. The register value is not signed. 0x80 is no offset.
> > 
> 
> Heh, you are actually quite right. Even though it working correctly, it is
> because the value that gets written to the register is val & 0xFF, so adding
> or subtracting here basically has the same effect. But subtracting is the more
> logical way to do it. (I tested it that way too just to be 100% sure.)

Yeps, when testing it i realized that the current form just gives the correct
value in the 2 LSB so I assumed we were doing something to cast way the invalid
bits.

To be more pedantic, I think subtracting is the *correct* way :)

- Nuno Sá

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ