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

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.

-- 
With Best Regards,
Andy Shevchenko