linux-kernel - Re: [PATCH v5 3/3] iio: light: Add support for APDS9306 Light Sensor

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]

Message-ID: <fd404067-bc24-449c-94b4-f59a54c3f532@tweaklogic.com>
Date: Sun, 4 Feb 2024 21:53:55 +1030
From: Subhajit Ghosh <subhajit.ghosh@...aklogic.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Matti Vaittinen <mazziesaccount@...il.com>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Marek Vasut <marex@...x.de>, Anshul Dalal <anshulusr@...il.com>,
 Javier Carrasco <javier.carrasco.cruz@...il.com>,
 Matt Ranostay <matt@...ostay.sg>,
 Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@...s.com>,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/3] iio: light: Add support for APDS9306 Light Sensor

Hi Jonathan,
>>
>>> +
>>> +static struct iio_event_spec apds9306_event_spec_als[] = {
>>> +    {
>>> +        .type = IIO_EV_TYPE_THRESH,
>>> +        .dir = IIO_EV_DIR_RISING,
>>> +        .mask_shared_by_all = BIT(IIO_EV_INFO_VALUE),
>>> +    }, {
>>> +        .type = IIO_EV_TYPE_THRESH,
>>> +        .dir = IIO_EV_DIR_FALLING,
>>> +        .mask_shared_by_all = BIT(IIO_EV_INFO_VALUE),
>>> +    }, {
>>> +        .type = IIO_EV_TYPE_THRESH,
>>> +        .mask_shared_by_all = BIT(IIO_EV_INFO_PERIOD),
>>> +    }, {
>>> +        .type = IIO_EV_TYPE_THRESH_ADAPTIVE,
>>> +        .mask_shared_by_all = BIT(IIO_EV_INFO_VALUE) |
>>> +            BIT(IIO_EV_INFO_ENABLE),
>>> +    }, {
>>> +        .mask_separate = BIT(IIO_EV_INFO_ENABLE),
>>
>> What's the intent of this final entry?
>> The type will default to IIO_EV_TYPE_THRESH anyway but if that
>> the intent you should specify it.   There isn't an 'obvious'
>> default for type in the same way there sort of is for dir
>> (as it's either direction).
> Understood, let me experiment and see the ABI difference, if any and get back to you.
> 
This device has two channels - ALS and CLEAR. One interrupt enable option and
one Channel selection option (Clear or ALS). According to our previous discussions:
https://lore.kernel.org/all/20230415183543.6d5e3392@jic23-huawei/
the event_spec was updated to have two interrupt enable attributes - one for CLEAR and
one for ALS. (Intensity channel and Illuminance channel)

If I remove the final entry I am getting only one enable option (intensity channel):
/sys/bus/iio/devices/iio:device0/
|-- events
|   |-- in_intensity_clear_thresh_either_en
|   |-- thresh_adaptive_either_en
|   |-- thresh_adaptive_either_value
|   |-- thresh_adaptive_either_values_available
|   |-- thresh_either_period
|   |-- thresh_either_period_available
|   |-- thresh_falling_value
|   `-- thresh_rising_value

The last entry gives be the following event attributes, enable attributes for both
intensity and illuminance channels:
/sys/bus/iio/devices/iio:device0/
|-- events
|   |-- in_illuminance_thresh_either_en
|   |-- in_intensity_clear_thresh_either_en
|   |-- thresh_adaptive_either_en
|   |-- thresh_adaptive_either_value
|   |-- thresh_adaptive_either_values_available
|   |-- thresh_either_period
|   |-- thresh_either_period_available
|   |-- thresh_falling_value
|   `-- thresh_rising_value

Please let me know if this sounds ok to you.

Regards,
Subhajit Ghosh