All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
Cc: linux-iio@vger.kernel.org,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, "Kees Cook" <kees@kernel.org>,
	"Gustavo A . R . Silva" <gustavoars@kernel.org>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Luca Weiss" <luca.weiss@fairphone.com>
Subject: Re: [PATCH v2 0/5] iio: light: stk3310: per-chip match data and STK36C61 support
Date: Mon, 31 Aug 2026 00:48:37 +0100	[thread overview]
Message-ID: <20260831004837.406a1108@jic23-huawei> (raw)
In-Reply-To: <20260826175409.326131-1-jorijnvdgraaf@catcrafts.net>

On Wed, 26 Aug 2026 19:54:04 +0200
Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net> wrote:

> 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/
> 
FWIW I took another look through and with those small things Andy raised
tidied up (including a more concise commit message for the final patch) this
looks good to go to me.

Thanks,

Jonathan

      parent reply	other threads:[~2026-08-30 23:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 17:54 [PATCH v2 0/5] iio: light: stk3310: per-chip match data and STK36C61 support Jorijn van der Graaf
2026-08-26 17:54 ` [PATCH v2 1/5] iio: light: stk3310: lower-case the i2c device ID names Jorijn van der Graaf
2026-08-26 18:03   ` sashiko-bot
2026-08-27  6:45   ` Andy Shevchenko
2026-08-26 17:54 ` [PATCH v2 2/5] dt-bindings: iio: light: stk33xx: document the Sensortek STK36C61 Jorijn van der Graaf
2026-08-26 17:54 ` [PATCH v2 3/5] iio: light: stk3310: move the data registers into the channel address Jorijn van der Graaf
2026-08-26 18:07   ` sashiko-bot
2026-08-27  6:47   ` Andy Shevchenko
2026-08-26 17:54 ` [PATCH v2 4/5] iio: light: stk3310: add per-chip match data Jorijn van der Graaf
2026-08-26 18:03   ` sashiko-bot
2026-08-27  7:47   ` Andy Shevchenko
2026-08-26 17:54 ` [PATCH v2 5/5] iio: light: stk3310: support the Sensortek STK36C61 Jorijn van der Graaf
2026-08-27  7:53   ` Andy Shevchenko
2026-08-28  4:18   ` Marcelo Schmitt
2026-08-28 15:47     ` Jorijn van der Graaf
2026-08-30 15:03       ` Marcelo Schmitt
2026-08-30 20:19         ` Jorijn van der Graaf
2026-08-31  7:53           ` Luca Weiss
2026-09-01  0:54             ` Marcelo Schmitt
2026-09-01  1:28               ` Marcelo Schmitt
2026-09-01  2:55                 ` Jorijn van der Graaf
2026-09-01  6:57                   ` Luca Weiss
2026-08-30 23:48 ` Jonathan Cameron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260831004837.406a1108@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=gustavoars@kernel.org \
    --cc=jorijnvdgraaf@catcrafts.net \
    --cc=kees@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.weiss@fairphone.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.