Re: [PATCH 2/2] hwmon: Add support for D3-323-AA Pyroelectric IR sensor

Re: [PATCH 2/2] hwmon: Add support for D3-323-AA Pyroelectric IR sensor

[Guenter Roeck]

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@axis.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 ?

Guenter

Re: [PATCH 2/2] hwmon: Add support for D3-323-AA Pyroelectric IR sensor

[Jonathan Cameron]

On Wed, 11 Dec 2024 22:17:49 -0800
Guenter Roeck <linux@roeck-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@axis.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


> 
> Guenter
> 
> 

Re: [PATCH 2/2] hwmon: Add support for D3-323-AA Pyroelectric IR sensor

[Hermes Zhang]

Hi

On 2024/12/13 0:59, Jonathan Cameron wrote:
> On Wed, 11 Dec 2024 22:17:49 -0800
> Guenter Roeck <linux@roeck-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@axis.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?

Best Regards,
Hermes

Re: [PATCH 2/2] hwmon: Add support for D3-323-AA Pyroelectric IR sensor

[Jonathan Cameron]

On Fri, 13 Dec 2024 13:39:01 +0800
Hermes Zhang <chenhuiz@axis.com> wrote:

> Hi
> 
> On 2024/12/13 0:59, Jonathan Cameron wrote:
> > On Wed, 11 Dec 2024 22:17:49 -0800
> > Guenter Roeck <linux@roeck-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@axis.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
> 
>