linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Ivan Mikhaylov <i.mikhaylov@yadro.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Jean Delvare <jdelvare@suse.com>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-hwmon@vger.kernel.org
Subject: Re: [PATCH 4/4] hwmon: vcnl3020: add hwmon driver for intrusion sensor
Date: Wed, 5 May 2021 07:02:08 -0700	[thread overview]
Message-ID: <20210505140208.GA1913659@roeck-us.net> (raw)
In-Reply-To: <8dbdf071f9f2041b92cabfa417487a3ec3e9647e.camel@yadro.com>

On Tue, May 04, 2021 at 10:46:53PM +0300, Ivan Mikhaylov wrote:
> On Fri, 2021-04-30 at 09:38 -0700, Guenter Roeck wrote:
> > On Fri, Apr 30, 2021 at 06:24:19PM +0300, Ivan Mikhaylov wrote:
> > > Intrusion status detection via Interrupt Status Register.
> > > 
> > > Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
> > 
> > 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?
> 
> > 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?".
> 

The cost for VCNL3020, for a full reel with 3,300 chips, is $1.17 per chip
at Mouser. A mechanical switch costs a couple of cents. A single proximity
sensor won't cover all parts of a chassis; one would likely need several
chips to be sure that are no blind spots (if that is even possible - I don't
think it is in any of my PC chassis due to mechanical limitations). This
is on top of programming, which would be sensitive to generating false
alarms (or missing alarms, for that matter). That sounds quite impractical
and expensive to me. I'd really like to see the actual use case where a
proximity sensor (or set of proximity sensors) is used for intrusion
detection in the sense of hardware monitoring - not just the technical
possibility of doing so, but an actual use case (as in "this vendor,
in this chassis, is doing it").

Thanks,
Guenter

  parent reply	other threads:[~2021-05-05 14:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 15:24 [PATCH 0/4] add periodic mode, threshold options and hwmon Ivan Mikhaylov
2021-04-30 15:24 ` [PATCH 1/4] iio: proximity: vcnl3020: add periodic mode Ivan Mikhaylov
2021-05-01 18:48   ` Andy Shevchenko
2021-05-02 18:00   ` Jonathan Cameron
2021-05-04 19:07     ` Ivan Mikhaylov
2021-05-05  8:22       ` Jonathan Cameron
2021-04-30 15:24 ` [PATCH 2/4] iio: proximity: vcnl3020: add threshold options Ivan Mikhaylov
2021-05-01 18:51   ` Andy Shevchenko
2021-04-30 15:24 ` [PATCH 3/4] iio: proximity: vncl3020: remove mutex from vcnl3020_data Ivan Mikhaylov
2021-05-01 18:53   ` Andy Shevchenko
2021-05-02 17:53   ` Jonathan Cameron
2021-04-30 15:24 ` [PATCH 4/4] hwmon: vcnl3020: add hwmon driver for intrusion sensor Ivan Mikhaylov
2021-04-30 16:38   ` Guenter Roeck
2021-05-04 19:46     ` Ivan Mikhaylov
2021-05-05  8:26       ` Jonathan Cameron
2021-05-05 14:02       ` Guenter Roeck [this message]
2021-05-17 17:08         ` Ivan Mikhaylov
2021-05-01  7:07   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210505140208.GA1913659@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=i.mikhaylov@yadro.com \
    --cc=jdelvare@suse.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).