[PATCH v2 0/5] iio: light: stk3310: per-chip match data and STK36C61 support

[Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>]

The Sensortek STK36C61 is a 3-in-1 ambient light / proximity / RGB
colour sensor whose register interface is compatible with the stk3310
across the ALS and proximity data, threshold, gain and
integration-time registers this driver uses. The part name comes from
the Fairphone 6 manual, which lists the component as "3IN1 ALPS/RGB
sensor/STK36C61". There is no public datasheet; the layout was probed
on the device: chip ID 0x95, the stk3310 STATE/FLAG bit layout, data
and threshold registers, gain steps that scale the ALS reading
accordingly, and an RGBC data block directly after the ALS data.

Since v1 the colour block's controls were located, confirming
Jonathan's guess on v1's patch 3 that they sit in a register we had
not found: the STK37660 datasheet, a documented sibling with the same
data register layout, places a clear-channel gain field in a GAINCTRL
register at 0x4E, split from the RGB gain in ALSCTRL, and stepping it
on the STK36C61 multiplies the clear count by ~4 per step while the
other channels hold still. The STK36C61 patch therefore now exposes
scale and integration time on the colour channels.

Tested on a Fairphone 6 running a 7.2-based tree: this series'
stk3310.c, byte-identical, built as a module against that tree (the
i2c core files the binding behaviour depends on are identical between
the trees). Verified there: DT boot instantiation, the colour
scale/integration-time interface, and the sysfs name behaviours this
series changes: a lower-case name selects the full profile through
the id table, capitals no longer bind, and a full-compatible-string
client now fails probe with the missing-driver-data error. A board
DTS node using the new compatible follows separately via
linux-arm-msm.

Changes in v2:
- new first patch lower-casing the i2c device ID names (Andy), and
  probe now fails on missing match data instead of falling back to
  the stk3310 profile (Andy)
- new precursor patch moving the data registers into the channel
  .address field (Jonathan), split out of the match-data patch; the
  bulk read gains a regmap local variable (Andy)
- the ACPI table entries use named initializers (Jonathan)
- the STK36C61 patch exposes scale and integration time on the colour
  channels (Jonathan's suggestion on v1 patch 3; the clear-gain
  register located via the STK37660 datasheet and verified on the
  device). With those branches of read_raw now handling the intensity
  channels, the ret = -EINVAL single-exit form promised on the v1
  thread (Andy) has no unreachable branch left to apply to
- picked up Krzysztof's Reviewed-by on the binding patch

v1: https://lore.kernel.org/all/20260810110423.41697-1-jorijnvdgraaf@catcrafts.net/

Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>

Jorijn van der Graaf (5):
  iio: light: stk3310: lower-case the i2c device ID names
  dt-bindings: iio: light: stk33xx: document the Sensortek STK36C61
  iio: light: stk3310: move the data registers into the channel address
  iio: light: stk3310: add per-chip match data
  iio: light: stk3310: support the Sensortek STK36C61

 Documentation/ABI/testing/sysfs-bus-iio       |   1 +
 .../bindings/iio/light/stk33xx.yaml           |   9 +-
 drivers/iio/light/stk3310.c                   | 203 +++++++++++++-----
 3 files changed, 156 insertions(+), 57 deletions(-)


base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425
-- 
2.55.0