Received-SPF: pass (google.com: domain of linux-kernel+bounces-51676-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Sun, 4 Feb 2024 13:40:56 +0000
From: Jonathan Cameron <jic23@kernel.org>
To: Subhajit Ghosh <subhajit.ghosh@tweaklogic.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>, Rob Herring <robh+dt@kernel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley
 <conor+dt@kernel.org>, Matti Vaittinen <mazziesaccount@gmail.com>, Andy
 Shevchenko <andriy.shevchenko@linux.intel.com>, Marek Vasut
 <marex@denx.de>, Anshul Dalal <anshulusr@gmail.com>, Javier Carrasco
 <javier.carrasco.cruz@gmail.com>, Matt Ranostay <matt@ranostay.sg>, Stefan
 Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com>,
 linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/3] iio: light: Add support for APDS9306 Light
 Sensor
Message-ID: <20240204134056.5dc64e8b@jic23-huawei>
In-Reply-To: <fd404067-bc24-449c-94b4-f59a54c3f532@tweaklogic.com>
References: <20240121051735.32246-1-subhajit.ghosh@tweaklogic.com>
	<20240121051735.32246-4-subhajit.ghosh@tweaklogic.com>
	<20240121152332.6b15666a@jic23-huawei>
	<757a18b7-94f4-4d72-9917-5d8b1cd677f6@tweaklogic.com>
	<fd404067-bc24-449c-94b4-f59a54c3f532@tweaklogic.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 4 Feb 2024 21:53:55 +1030
Subhajit Ghosh <subhajit.ghosh@tweaklogic.com> wrote:

> Hi Jonathan,
> >> =20
> >>> +
> >>> +static struct iio_event_spec apds9306_event_spec_als[] =3D {
> >>> +=C2=A0=C2=A0=C2=A0 {
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .type =3D IIO_EV_TYPE_THR=
ESH,
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .dir =3D IIO_EV_DIR_RISIN=
G,
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .mask_shared_by_all =3D B=
IT(IIO_EV_INFO_VALUE),
> >>> +=C2=A0=C2=A0=C2=A0 }, {
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .type =3D IIO_EV_TYPE_THR=
ESH,
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .dir =3D IIO_EV_DIR_FALLI=
NG,
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .mask_shared_by_all =3D B=
IT(IIO_EV_INFO_VALUE),
> >>> +=C2=A0=C2=A0=C2=A0 }, {
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .type =3D IIO_EV_TYPE_THR=
ESH,
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .mask_shared_by_all =3D B=
IT(IIO_EV_INFO_PERIOD),
> >>> +=C2=A0=C2=A0=C2=A0 }, {
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .type =3D IIO_EV_TYPE_THR=
ESH_ADAPTIVE,
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .mask_shared_by_all =3D B=
IT(IIO_EV_INFO_VALUE) |
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=
IT(IIO_EV_INFO_ENABLE),
> >>> +=C2=A0=C2=A0=C2=A0 }, {
> >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .mask_separate =3D BIT(II=
O_EV_INFO_ENABLE), =20
> >>
> >> 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.=C2=A0=C2=A0 There isn't an 'obvious'
> >> default for type in the same way there sort of is for dir
> >> (as it's either direction). =20
> > Understood, let me experiment and see the ABI difference, if any and ge=
t back to you.
> >  =20
> This device has two channels - ALS and CLEAR. One interrupt enable option=
 and
> one Channel selection option (Clear or ALS). According to our previous di=
scussions:
> 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)
>=20
> If I remove the final entry I am getting only one enable option (intensit=
y 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
>=20
> 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
>=20
> Please let me know if this sounds ok to you.
Looks like coincidence of enum values being 0.
It's really
{
	.type =3D IIO_EV_TYPE_THRESH, /* Value 0 */
	.dir =3D IIO_EV_DIR_EITHER, /* value 0 */
	.mask_separate =3D BIT(IIO_EV_INFO_ENABLE),

Dropping 'defaults' for these things is fine if they are the obvious default
or other parameters mean they aren't used, but that isn't the case here so
please be explicit for all the values that are used.

You can put this final mask a few lines earlier as the other fields match
anyway.
	{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 	.type =3D IIO_EV_TYPE_THRESH,
		.dir =3D IIO_EV_DIR_EITHER,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 	.mask_shared_by_all =3D BIT(IIO=
_EV_INFO_PERIOD),
		.mask_separate =3D BIT(IIO_EV_INFO_ENABLE),
	},..

>=20
> Regards,
> Subhajit Ghosh