Re: [PATCH v7 0/4] iio: light: add support for veml6031x00 ALS series

On Tue, 18 Aug 2026 17:02:35 +0300
Andy Shevchenko <[email protected]> wrote:

> On Tue, Aug 18, 2026 at 01:34:25PM +0200, Javier Carrasco wrote:
> > These ambient light sensors with I2C interface provide two light
> > channels (ALS and IR), high/low threshold alarms with configurable
> > persistence, and a data ready signal.
> > 
> > The devices covered by this driver have the same resolution, and they
> > share most of their functionality. These are the differences between
> > them (note that the x belongs to their names, and it is not a wildcard):
> > 
> >  - Device ID: accessible via two 8-bit registers, different values for
> >    veml6031x00/veml6031x01 and veml60311x00/veml60311x01.
> >  - I2C address: same grouping, 0x29 and 0x10 I2C addresses.
> >  - AEC qualification: AEC-Q100 for veml6031x00/veml60311x00 and
> >    AEC-Q101 for veml6031x01/veml60311x01.
> > 
> > The alarms and the data ready signals share the interrupt pin, and an
> > interrupt status register must be accessed to identify the source. Such
> > multiplexing is not new in IIO, and I have followed existing examples
> > for it. The persistence setting (own attribute) to trigger the alarms
> > uses the pattern that has already been used for the veml6030.
> > 
> > The device configuration is in general documented in the datasheet and
> > the application note. There is an exception, though: the activation of
> > the "active force" mode that is required for the data ready signal must
> > be carried out in two steps even though the affected bits are located in
> > the same register: first ALS_AF (active force mode enable) must be set,
> > and then ALS_TRIG (active force trigger setting) must be enabled. I have
> > added a brief commentary in the code to explain this behavior, which has
> > been confirmed by the manufacturer.
> > 
> > The datasheet specifies the scale and integration time for the ALS channel.
> > Although both settings also affect the measured IR value, no transfer
> > function, accuracy, or calibration is specified for converting the IR
> > output into a physical quantity. The IR channel is therefore intended only
> > as a qualitative indication of the infrared content of the incident light,
> > rather than as a precision measurement channel. Consequently, the driver
> > does not expose scale or integration time as IR-channel attributes.
> > 
> > The only functionality that has not been implemented yet is the x0.66
> > gain (and its x0.165 counterpart when PD_DIV=1), which makes the gts
> > helpers less usable due to the conversions required. It is indeed an
> > uncommon gain to use (there are x0.5 and x0.125 gains) with no known
> > use-case at the moment that justifies making adjustments to the gts
> > helpers or adding artificial conversions to make it work.
> > 
> > This driver has been tested with the four supported devices separately
> > as well as in pairs where the I2C addresses don't overlap.  
> 
> Reviewed-by: Andy Shevchenko <[email protected]>
> for all patches, but DT.
> 
> There are minor things that may be addressed later, or in next version if asked
> for other reasons.
> 
Assuming remaining discussion resolves, there is just enough requested
here that I think a v8 makes sense.  This is particularly because
of where we are in the cycle and the massive amount of time we have
as a result.

Note I didn't find anything that Andy hadn't already raised.
Looking nice!

Jonathan