On Tue, 4 May 2021 22:46:53 +0300
Ivan Mikhaylov [off-list ref] wrote:

On Fri, 2021-04-30 at 09:38 -0700, Guenter Roeck wrote:

quoted

On Fri, Apr 30, 2021 at 06:24:19PM +0300, Ivan Mikhaylov wrote:  

quoted

Intrusion status detection via Interrupt Status Register.

Signed-off-by: Ivan Mikhaylov <redacted>  

I think this should, if at all, be handled using the
iio->hwmon bridge (or, in other words, require a solution
which is not chip specific).  

Thanks a lot for suggestion, it's actually looks what's needed here instead of
this driver. Anyways, there is no IIO_PROXIMITY support inside supported types
in iio_hwmon.c. Should I add additional case inside this driver for
IIO_PROXIMITY type?

quoted

I am also not sure if "proximity" is really appropriate to use
for intrusion detection in the sense of hardware monitoring.
This would require a proximity sensor within a chassis, which
would be both overkill and unlikely to happen in the real world.
"Intrusion", in hardware monitoring context, means "someone
opened the chassis", not "someone got [too] close".
  

I'm not sure either but it exists :) And it's exactly for this purpose:
"someone opened the chassis", "how near/far is cover?".

Hmm. So we will have somewhat of an impedance mismatch.

In IIO events are push based (typically interrupt driven).
There is also the issue that we don't currently have in kernel
interfaces to allow drivers like iio-hwmon to use them (there
has never been enough demand though it has been discussed a few
times).   As such we'd need to implement the core support for
that as well.   We might get away with some simplifications that
make this not too painful - e.g. avoid the need to filter events
by stating that a consumer may well get events it's not interested
in and it is up to the consumer to check (a later optimization could
then add filtering similar to what we do for main data flows).

Jonathan