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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250222120537.13d2998e@jic23-huawei>
Date: Sat, 22 Feb 2025 12:05:37 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Svyatoslav Ryhel <clamor95@...il.com>
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

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.

Jonathan

> you
>