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: <b296a23d-bc65-481c-a194-cb16535d8c24@baylibre.com>
Date: Mon, 18 Nov 2024 14:48:02 -0600
From: David Lechner <dlechner@...libre.com>
To: Guillaume Ranquet <granquet@...libre.com>,
 Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Jonathan Cameron <jic23@...nel.org>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] iio: adc: ad7173: add openwire detection support for
 single conversions

On 11/15/24 4:34 AM, Guillaume Ranquet wrote:
> Some chips of the ad7173 family supports open wire detection.
> 
> Generate a threshold event whenever an external source is disconnected
> from the system input on single conversions.
> 
> Signed-off-by: Guillaume Ranquet <granquet@...libre.com>
> ---
> Hi.
> 
> This patch adds the openwire detection support for the ad4111 chip.
> 
> The openwire detection is done in software and relies on comparing the
> results of two conversions on different channels.
> 
> As presented here, the code sends a THRESH Rising event tied to the
> in_voltageX_raw channel on which it happened.
> 
> We think this is not correct but we can't seem to find an implementation
> that would be elegant.
> 
> The main idea would be to add a specific channel for openwire detection
> but we still would need to have the openwire enablement and threshold
> tied to the voltage channel.
> 
> Any thought on this?
> 
Just to spell this out in a bit more detail, my understanding is that
the procedure works like this...

To detect an open wire on a single-ended input, we measure the voltage
on pin VIN0 using channel register 15, the we read the voltage on the
same pin again using channel register 0. The datasheet isn't clear on
the details, but on one or the other or both of these, the ADC chip is
applying some kind of pull up or pull down on the input pin so that
each measurement will be nearly the same if there is a wire attached
with a 0-10V signal on it. Or if the wire is detached and the pins are
left floating, the two measurements will be different (> 300 mV).

So this threshold value (the 300 mV) is measured in terms of the
difference between two voltage measurements, but of the same input pin.

My suggestion is to create extra differential channels like
in_voltage0-involtage100_* where 100 is an arbitrary number. These
channels would be defined as the difference between the two measurements
on the same pin. The event attributes would use these channels since they
are triggered by exceeding the threshold value according to this difference
measurement.

To complicate matters, these chips can also be configured so that two
input pins can be configured as a fully differential pair. And we can
also do open wire detection on these differential pairs. In this case
we would configure input pins VIN0 and VIN1 as a differential pair, then
read the difference of those two pins using channel register 1, then
read again using channel register 2. The we see if the difference of the
two differences exceeds the threshold.

In this case, we can't have in_(voltage0-voltage1)-(voltage100-voltage101)_*
attributes. So I guess we would have to do something like
in_voltage200-voltage300 to handle this case? (voltage200 would represent
the first measurement of voltage0-voltage1 and voltage300 would represent
the 2nd measurement of the same).



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ