linux-kernel - Re: [PATCH v2 2/3] iio: light: Add support for AL3000a illuminance 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] [day] [month] [year] [list]

Message-ID: <CAPVz0n04RCb9DWVScBR00Zk+PQBwpnjKSbig2D6yr0-hoej1kQ@mail.gmail.com>
Date: Sat, 22 Feb 2025 14:11:09 +0200
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, 
	Javier Carrasco <javier.carrasco.cruz@...il.com>, Matti Vaittinen <mazziesaccount@...il.com>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Emil Gedenryd <emil.gedenryd@...s.com>, 
	Arthur Becker <arthur.becker@...tec.com>, Mudit Sharma <muditsharma.info@...il.com>, 
	Per-Daniel Olsson <perdaniel.olsson@...s.com>, Subhajit Ghosh <subhajit.ghosh@...aklogic.com>, 
	Ivan Orlov <ivan.orlov0322@...il.com>, David Heidelberg <david@...t.cz>, linux-iio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-tegra@...r.kernel.org
Subject: Re: [PATCH v2 2/3] iio: light: Add support for AL3000a illuminance sensor

сб, 22 лют. 2025 р. о 14:05 Jonathan Cameron <jic23@...nel.org> пише:
>
> On Mon, 17 Feb 2025 16:32:33 +0200
> Svyatoslav Ryhel <clamor95@...il.com> wrote:
>
> > пн, 17 лют. 2025 р. о 16:24 Jonathan Cameron <jic23@...nel.org> пише:
> > >
> > >
> > > Hi,
> > >
> > > > > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > > > > +                         struct iio_chan_spec const *chan, int *val,
> > > > > > +                         int *val2, long mask)
> > > > > > +{
> > > > > > +     struct al3000a_data *data = iio_priv(indio_dev);
> > > > > > +     int ret, gain;
> > > > > > +
> > > > > > +     switch (mask) {
> > > > > > +     case IIO_CHAN_INFO_RAW:
> > > > > > +             ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > > > > +             if (ret < 0)
> > > > > > +                     return ret;
> > > > > > +
> > > > > > +             *val = lux_table[gain & AL3000A_GAIN_MASK];
> > > > >
> > > > > I may have misinterpreted the other thread.  IS this value in lux?
> > > > > If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
> > > > >
> > > >
> > > > This is actually a really good hint, I will check if this works out
> > > > and if yes, then definitely will use it. Thank you.
> > >
> > > From your other reply it seems we have no idea of the correct scaling.
> > > If that is the case, then channel type should be IIO_INTENSITY as
> > > I assume we also have no idea if the light sensitivity curve is
> > > matched to that required for illuminance (which approximates the
> > > sensitivity of the human eye). Various datasheets provide completely
> > > garbage conversion formulas btw so even if we have data this can
> > > be problematic. One recent sensor was using a green filter and
> > > saying illuminance in lux was 1.2 * green which was assuming their
> > > own definition of white light.
> > >
> > > Jonathan
> > >
> >
> > Then why IIO_LIGHT exists at all? If you state that datasheets provide
> > garbage formulas and sensors cannot be trusted and all is around human
> > eye, then why IIO_LIGHT is still the case? I did not recall any
> > drivers for human eyes (thank god). Please be more consistent. Thank
>
> It exists because some sensors do this correctly, or at least a good
> approximation to the standard sensitivity curves.  This is done two
> ways.
>
> 1. Good light frequency filtering in front of the sensor to compensate
>    for the difference in sensitivity between the measuring element
>    and that the standard curves.  CIE1931 (there are a few other standards
>    but they are close enough that we don't care).
>    https://en.wikipedia.org/wiki/Illuminance
> 2. Multiple sensing elements. A common reason for this is to remove
>    bit of infrared that we don't want. Often the calculation is a
>    non linear combination of the various sensor outputs. Such a driver
>    usually presents several IIO_INTENSITY channels and a calculated
>    IIO_LIGHT channel.
>
> In both cases the datasheet tends to include a comparison the the
> CIE1931 etc standards. There will be small differences but that is
> very different from taking a sensor that is only sensitive to green
> and weighting it which is the example I gave above.
>
> These sensors will compensate for the different sensivity
> of the human eye to different wavelengths.  E.g. if you
> think blue and green light LEDs have the same brightness then
> the sensor will give close to the same output.
>
> Anyhow, light sensors are a hole I have gone far too deep in over
> the years. Key is some manufacturers provide insufficient information
> or take the view it is a problem for the integrator of the sensor
> to deal with. For those we do not pretend to know the answer and
> use intensity channels instead.
>

This is quite an explicit explanation. Thank you.

> Jonathan
>
>
> > you
> >
>