[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241214114603.7db6bdbc@jic23-huawei>
Date: Sat, 14 Dec 2024 11:46:03 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Hermes Zhang <chenhuiz@...s.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Guenter Roeck
<linux@...ck-us.net>, Hermes Zhang <Hermes.Zhang@...s.com>,
jdelvare@...e.com, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, kernel@...s.com, linux-kernel@...r.kernel.org,
linux-hwmon@...r.kernel.org, "linux-iio@...r.kernel.org"
<linux-iio@...r.kernel.org>
Subject: Re: [PATCH 2/2] hwmon: Add support for D3-323-AA Pyroelectric IR
sensor
On Fri, 13 Dec 2024 13:39:01 +0800
Hermes Zhang <chenhuiz@...s.com> wrote:
> Hi
>
> On 2024/12/13 0:59, Jonathan Cameron wrote:
> > On Wed, 11 Dec 2024 22:17:49 -0800
> > Guenter Roeck <linux@...ck-us.net> wrote:
> >
> >> Hi,
> >>
> >> On 12/11/24 20:24, Hermes Zhang wrote:
> >>> Add support for Nicera D3-323-AA Pyroelectric IR sensor. The sensor
> >>> support to config the threshold/filter_type/filter_step and return the
> >>> detect result in sysfs attribute.
> >>>
> >>> Signed-off-by: Hermes Zhang <Hermes.Zhang@...s.com>
> >>> ---
> >>>
> >> ...
> >>
> >>> +
> >>> +static DEVICE_ATTR_WO(pir_threshold);
> >>> +static DEVICE_ATTR_WO(pir_filter_step);
> >>> +static DEVICE_ATTR_WO(pir_filter_type);
> >>> +static DEVICE_ATTR_RO(pir_detector);
> >>> +
> >>> +static struct attribute *d3323aa_attrs[] = {
> >>> + &dev_attr_pir_threshold.attr,
> >>> + &dev_attr_pir_filter_step.attr,
> >>> + &dev_attr_pir_filter_type.attr,
> >>> + &dev_attr_pir_detector.attr,
> >>> + NULL,
> >>> +};
> >>> +
> >>> +ATTRIBUTE_GROUPS(d3323aa);
> >>> +
> >> I don't know what this is, but it is most definitely not a hardware
> >> monitoring device. I don't see a definition of those attributes,
> >> so I have no idea what they represent.
> >>
> >> Maybe this is an iio device, but given the unusual attributes
> >> I am not even sure about that. Jonathan, any thoughts ?
> > New type of sensor, but sure could be in IIO.
> >
> > Seems mostly a human presence sensor. Not that different from some
> > types of proximity sensor and indeed that might be the path to take
> > here.
> >
> > Taking a quick look at the driver suggests there is lots more information
> > needed to understand the ABI. At very least needs ABI docs so we can
> > discuss how that is generalized. So if submitting an IIO driver
> > I want to see
> > Documenation/ABI/testing/sysfs-bus-iio-xxxx
> > with significant detail. The datasheet provides no where near enough
> > info.
> >
> > Jonathan
>
> Thanks for your suggestions. For the new sensor, it seems require three
> attributes, e.g. /sys/bus/iio/devices/iio:deviceX/in_threshold
> (in_filter_step, in_filter_type), then one data to indicate if it is
> been triggerred (bool), but I'm not sure what is sutible IIO type could
> it used? Do you have any suggestion?
Look at the existing ABI in Documentation/ABI/testing/sysfs-bus-iio
and aim to fit within that scheme.
I'm hoping you have access to a datasheet that tells you something about the
filters that lets you map them to something standard. Normally we aim
for something like 3DB frequency. Filter types are harder but there tend to
only be so many types people actually build.
Channel type wise, I'm thinking this is kind of a form of proximity sensor
so IIO_PROXIMITY is probably appropriate. That has always been a bit vague
as many proximity sensors are kind of 'there is something nearish' rather
than providing actual units etc.
It's a little different as I believe these only detect movement rather
than entirely static people, but in the case of the ones for presence detection
they work on tiny movements so more or less the same as detecting proximity.
Jonathan
>
> Best Regards,
> Hermes
>
>
Powered by blists - more mailing lists