linux-kernel - Re: [PATCH v3 2/3] iio: light: ltr390: Add ALS channel and support for gain and resolution

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240730192139.063b7a85@jic23-huawei>
Date: Tue, 30 Jul 2024 19:21:39 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Abhash jha <abhashkumarjha123@...il.com>
Cc: linux-iio@...r.kernel.org, anshulusr@...il.com, lars@...afoo.de,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] iio: light: ltr390: Add ALS channel and support
 for gain and resolution

On Tue, 30 Jul 2024 12:47:10 +0530
Abhash jha <abhashkumarjha123@...il.com> wrote:

> On Tue, Jul 30, 2024 at 1:23 AM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Mon, 29 Jul 2024 17:20:54 +0530
> > Abhash Jha <abhashkumarjha123@...il.com> wrote:
> >  
> > > Add new ALS channel and allow reading raw and scale values.
> > > Also provide gain and resolution configuration for ALS channel.
> > > Add automatic mode switching between the UVS and ALS channel
> > > based on which channel is being accessed.
> > > The default mode in which the sensor start is ALS mode.
> > >
> > > Signed-off-by: Abhash Jha <abhashkumarjha123@...il.com>  
> > Hi Abhash,
> >
> > Patch looks good but one quick question.
> > Why not present an IIO_LIGHT channel?  Needs to be converted
> > to be illuminance (with scale / offset applied) rather than IIO_INTENSITY
> > which we use when the frequency response is different from the requirements
> > to measure Lux (and the units get very vague!)
> >
> > Looks like what you have here is close, but not quite the right scale
> > factor as not including integration time and the mysterious 0.6 on the datasheet.  
> 
> Yes, I just noticed it now. I will provide the integration time and
> 0.6 as part of the
> scale calculation in the next version.
> 
> >
> > If we can provide a signal scaled to illuminance that tends to be a lot
> > more useful for things like screen brightness control because it should
> > be close at least to other light sensors.
> >  
> Hi Jonathan,
> It did not occur to me that the IIO_LIGHT channel could be used
> directly and hence I
> went with the IIO_INTENSITY approach.
> Yes we could provide the IIO_LIGHT channel and perform lux calculation
> in the driver.
> Would that mean forgoing the IIO_INTENSITY channel? Or do we keep both?

Expose the scaling as _scale for the light channel and don't expose
intensity (as it will be the _raw value anyway).

It's rare to see a linear function for intensity to lux transform but
I think there are one or two others like this.  Mostly the transform
is nonlinear and involves multiple intensity channels which is why
we normally have those and IIO_LIGHT.

Thanks,

Jonathan

> 
> Abhash
> 
> > Jonathan