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.
Maybe there any other good ways to deal with it? I'd be prefer 4.
Thanks.
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
On Tue, 2020-01-28 at 05:22 -0800, Guenter Roeck wrote:
> 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
Guenter,
that's what I meant about intrusion, sorry for being inaccurate. This proximity
sensor can be used as chassis intrusion detector, that's why I mentioned about
hwmon and possible interface for such thing.
Thanks.
On Tue, Jan 28, 2020 at 06:31:55PM +0300, Ivan Mikhaylov wrote:
> On Tue, 2020-01-28 at 05:22 -0800, Guenter Roeck wrote:
> > 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
>
> Guenter,
> that's what I meant about intrusion, sorry for being inaccurate. This proximity
> sensor can be used as chassis intrusion detector, that's why I mentioned about
> hwmon and possible interface for such thing.
>
This is most definitely not a common use case for such a chip. Similar,
one might argue that a light sensor could be used for chassis intrusion
detection, or a movement sensor (after all, moving a chassis could be
considered "intrusion", especially if it is a server chassis). Sure,
technically one can use pretty much anything for "intrusion detection",
but it is hard to imagine this as actual use case. This is made worse by
the need for calibration - one would need to be able to determine what
exactly defines "intrusion", and that would have to be chassis or even
board specific and can not be hardcoded. This is way out of scope for
a hardware monitoring driver.
If you indeed choose such an approach in your company's systems, please
use an iio driver.
Thanks,
Guenter