Re: [PATCH v2 5/5] iio: light: stk3310: support the Sensortek STK36C61

On Wed, Aug 26, 2026 at 07:54:09PM +0200, Jorijn van der Graaf wrote:
> The Sensortek STK36C61 is a 3-in-1 ambient light / proximity / RGB
> colour sensor (chip ID 0x95) found in the Fairphone 6. Its register
> interface is compatible with the feature set this driver uses:

> the STATE/FLAG bit layout, the data and threshold registers and the gain
> and integration-time fields, verified on that device (the ALS and
> proximity readings scale with their gain and integration-time fields,
> thresholds written through the event interface read back from the
> chip, and the FLAG near/far bit crosses with them).

Do we need this paragraph in the commit message? To me sounds like a good
for the cover letter.

> Add its chip ID to the known-ID list and the device table entries.

> Whenever the ALS engine runs, the chip also measures four colour
> channels, laid out directly after the ALS data as 16-bit big-endian
> values in R (0x15), G (0x17), B (0x19), C (0x1B) order;

> the R, G and B assignments were each confirmed by the matching channel
> dominating under red, green and blue illumination, and clear by its broadband
> response. The ALS data register tracks the green channel exactly.

Isn't it too many details? One may decode that.

> The colour controls, all verified on the device: R, G and B are gained
> by the same ALSCTRL gain field the illuminance channel uses, clear by
> a GAIN_F_C field in a GAINCTRL register at 0x4E (documented in the
> datasheet of the STK37660, a sibling part with the same data register
> layout; stepping it multiplies the clear count by ~4 per step while
> the other channels hold still), and the whole colour block integrates
> over the ALS integration time. Expose the channels with per-channel
> scale and a shared integration time, as suggested by Jonathan Cameron.

Again, too detailed description. Try to squeeze that AI puke straight to
the point. If one needs a Datasheet, add Datasheet: tag with an URL.

> The scale attributes reuse the driver's existing table rather than the
> iio-gts helper. The green channel equals the ALS data, so its scale
> must read identically to the pre-existing in_illuminance_scale, which
> has always been the gain selector alone with the integration time
> exposed separately; iio-gts would fold the integration time into the
> scale, and its scale writes may retune the integration time behind the
> illuminance channel's back. The pre-existing available-values files
> stay constant attributes; converting them to read_avail is a separate
> cleanup, as it changes the long-standing scale lists' text ("6.4"
> becomes "6.400000").

-- 
With Best Regards,
Andy Shevchenko