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]
Date: Fri, 16 Feb 2024 10:57:33 -0600
From: David Lechner <dlechner@...libre.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Alisa-Dariana Roman <alisadariana@...il.com>, alexandru.tachici@...log.com, 
	alisa.roman@...log.com, conor+dt@...nel.org, devicetree@...r.kernel.org, 
	krzysztof.kozlowski+dt@...aro.org, krzysztof.kozlowski@...aro.org, 
	lars@...afoo.de, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	michael.hennerich@...log.com, robh+dt@...nel.org, 
	Nuno Sa <nuno.sa@...log.com>
Subject: Re: [PATCH v3 5/5] iio: adc: ad7192: Add AD7194 support

On Fri, Feb 16, 2024 at 8:22 AM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Thu, 15 Feb 2024 11:13:19 -0600
> David Lechner <dlechner@...libre.com> wrote:
>

..

> >
> > Tables 22, 23 and 24 in the AD7194 datasheet show that this chip is
> > much more configurable than AD7192 when it comes to assigning
> > channels. There are basically no restrictions on which inputs can be
> > used together. So I am still confident that my suggestion is the way
> > to go for AD7194. (Although I didn't actually try it on hardware, so
> > can't be 100% confident. But at least 90% confident :-p)
>
> You would have to define a channel number for aincom.  There is an explicit
> example in the datasheet of it being at 2.5V using a reference supply.
>
> I wonder what expectation here is.  Allways a reference regulator on that pin, or
> an actually varying input? Maybe in long term we want to support both
> options - so if aincom-supply is provided these are single ended with
> an offset, but if not they are differential channels between channel X and
> channel AINCOM.
>
> Note though that this mode is described a pseudo differential which normally
> means a fixed voltage on the negative.
>
> So gut feeling from me is treat them as single ended and add an
> aincom-supply + the offsets that result if that is provided in DT and
> voltage from it is non 0.

Calling AINCOM a supply doesn't sound right to me since usually this
signal is coming somewhere external, i.e. you have a twisted pair
connected to AIN1 and AINCOM going to some signal source that may be
hot-pluggable and not known at compile time. As an example, if AINCOM
was modeled as a supply, then we would have to change the device tree
every time we changed the voltage offset on the signal generator while
we are testing using an evaluation board.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ