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

On Wed Aug 19, 2026 at 3:04 AM CEST, Jonathan Cameron wrote:
> 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

I agree, a v8 makes sense even if there is no extra feedback. Anyway, I
think I will wait for -rc1 to rebase, make sure that no conflicts arise,
and send the new version. That should give enough time in case someone
wants to chime in :)

Best regards,
Javier