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:   Tue, 28 Jan 2020 05:22:55 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Ivan Mikhaylov <i.mikhaylov@...ro.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: vcnl3020 hwmon/proximity driver

On 1/28/20 3:31 AM, Ivan Mikhaylov wrote:
> Hello, I want to make driver for vcnl3020 but not sure where should I put it.
> It's similar to vcnl40xx series which is already in iio/light/vcnl4000.c
> but it perfectly fits with hwmon intrusion detection concept
> (intrusion[0-*]_alarm), so I'm a little bit confused.
> 
> vcnl3020 - proximity sensor which mostly using for intrusion detection
> vcnl4020 - light and proximity sensor
> 
> Doc's links:
> https://www.vishay.com/docs/84150/vcnl3020.pdf
> https://www.vishay.com/docs/83476/vcnl4020.pdf
> 
> That's what I think about possible ways:
> 
> 1. just iio/proximity/vcnl3020.c
> 2. extend functionality inside vcnl4000.c with ifdefs and dts stuff and maybe
>     rename it with generalization inside
> 3. hwmon driver for intrusion detection inside drivers/hwmon
> 4. both iio/proximity/vcnl3020.c and hwmon/vcnl3020.c
>     Example: hwmon/wm8350-hwmon.c + mfd/wm8350-core.c
>     So, just make proximity driver, do the depend in Kconfig for hwmon driver
>     on proximity driver and use proximity driver calls if would be needed.
> 

"intrusion" in the context of hardware monitoring is for chassis intrusion,
not for intrusion into an area. This driver should reside in iio.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ