Add support for AS7343 multi-spectral sensor

Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of 0x39.

Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf

Signed-off-by Chang Yu <[email protected]>

 .../bindings/iio/light/ams,as7343.yaml        | 72 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++
 2 files changed, 78 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yaml

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +13 -0

new file mode 100644
index 000000000000..d963832fb413
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/ams,as7343.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMS AS7343 14-Channel Multi-Spectral Sensor
+
+maintainers:
+  - Chang Yu <[email protected]>
+
+description: |
+  The AMS AS7343 is a 14-channel multi-spectral sensor with i2c address of 0x39.

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +8 -0

+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+
+additionalProperties: false

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 45

Quoted 12 lines · On Fri, 11 Sep 2026 18:39:11 -0700 Chang Yu <[email protected]> wrote:

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +12 -0

+    description:
+      The driver current for the external LED connected to the LDR pin.
+    minimum: 4000
+    maximum: 258000
+    multipleOf: 2000
+    default: 12000
+
+  sync-gpios:
+    description: |
+      Optional GPIO pin that can be used either as a synchronization input to
+      start/stop measurement or as an external start/stop signal for
+      synchronizing with the connected LED.

So the datasheet starts referring to using this for some level of sync but then only actually treats it as as a gpio (maybe I'm missing something). Any idea what that stuff about start/stop is talking about?

The only thing I can find about this is the device diagram in figure 13 that has the GPIO wired to the led driver and the automatic measurement engine.

Quoted 8 lines

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +8 -0

+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+
+additionalProperties: false

Hi Jonathan,

A quick comment inline.

Quoted 16 lines · Jonathan Cameron

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 45

Quoted 12 lines · On Fri, 11 Sep 2026 18:39:11 -0700 Chang Yu <[email protected]> wrote:

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +12 -0

+    description:
+      The driver current for the external LED connected to the LDR pin.
+    minimum: 4000
+    maximum: 258000
+    multipleOf: 2000
+    default: 12000
+
+  sync-gpios:
+    description: |
+      Optional GPIO pin that can be used either as a synchronization input to
+      start/stop measurement or as an external start/stop signal for
+      synchronizing with the connected LED.  

Quoted 7 lines

So the datasheet starts referring to using this for some level of sync but then only actually treats it as as a gpio (maybe I'm missing something). Any idea what that stuff about start/stop is talking about?

The only thing I can find about this is the device diagram in figure 13 that has the GPIO wired to the led driver and the automatic measurement engine.

That's what I got from the datasheet as well. They don't describe how to use the GPIO pin to perform synchronizations at all.

The adafruit arduino driver
(https://github.com/adafruit/Adafruit_AS7343/blob/main/Adafruit_AS7343.cpp)
is slightly more helpful - the GPIO in output mode signals when the spectral measurement starts. Unfortunately no information about input mode.

Quoted 11 lines

Quoted 9 lines

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +8 -0

+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+
+additionalProperties: false  

Quoted 28 lines · On Sat, 12 Sep 2026 18:35:14 -0700 Chang Yu <[email protected]> wrote:

Hi Jonathan,

A quick comment inline.

Quoted 16 lines · Jonathan Cameron

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 45

Quoted 12 lines · On Fri, 11 Sep 2026 18:39:11 -0700 Chang Yu <[email protected]> wrote:

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +12 -0

+    description:
+      The driver current for the external LED connected to the LDR pin.
+    minimum: 4000
+    maximum: 258000
+    multipleOf: 2000
+    default: 12000
+
+  sync-gpios:
+    description: |
+      Optional GPIO pin that can be used either as a synchronization input to
+      start/stop measurement or as an external start/stop signal for
+      synchronizing with the connected LED.  

Quoted 7 lines

So the datasheet starts referring to using this for some level of sync but then only actually treats it as as a gpio (maybe I'm missing something). Any idea what that stuff about start/stop is talking about?

The only thing I can find about this is the device diagram in figure 13 that has the GPIO wired to the led driver and the automatic measurement engine.

Quoted 8 lines

That's what I got from the datasheet as well. They don't describe how to use the GPIO pin to perform synchronizations at all.

The adafruit arduino driver
(https://github.com/adafruit/Adafruit_AS7343/blob/main/Adafruit_AS7343.cpp)
is slightly more helpful - the GPIO in output mode signals when the spectral measurement starts. Unfortunately no information about input mode.

There is no separate control? If so we can't use it as a GPIO as whilst there is a control to set the state it will randomly get overwritten if we do such a read. So to me sounds like that is there for testing the connection and similar usecases only and we should not expose this as a GPIO. Maybe input is possible but that may also have side effects. So I'd be tempted to drop it from the binding - with some description of why it is not there in the patch description.

Quoted 12 lines

Quoted 11 lines

Quoted 9 lines

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +8 -0

+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+
+additionalProperties: false  

Quoted 40 lines · Jonathan Cameron

Quoted 28 lines · On Sat, 12 Sep 2026 18:35:14 -0700 Chang Yu <[email protected]> wrote:

Hi Jonathan,

A quick comment inline.

Quoted 16 lines · Jonathan Cameron

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 45

Quoted 12 lines · On Fri, 11 Sep 2026 18:39:11 -0700 Chang Yu <[email protected]> wrote:

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +12 -0

+    description:
+      The driver current for the external LED connected to the LDR pin.
+    minimum: 4000
+    maximum: 258000
+    multipleOf: 2000
+    default: 12000
+
+  sync-gpios:
+    description: |
+      Optional GPIO pin that can be used either as a synchronization input to
+      start/stop measurement or as an external start/stop signal for
+      synchronizing with the connected LED.    

Quoted 7 lines

So the datasheet starts referring to using this for some level of sync but then only actually treats it as as a gpio (maybe I'm missing something). Any idea what that stuff about start/stop is talking about?

The only thing I can find about this is the device diagram in figure 13 that has the GPIO wired to the led driver and the automatic measurement engine.

Quoted 8 lines

That's what I got from the datasheet as well. They don't describe how to use the GPIO pin to perform synchronizations at all.

The adafruit arduino driver
(https://github.com/adafruit/Adafruit_AS7343/blob/main/Adafruit_AS7343.cpp)
is slightly more helpful - the GPIO in output mode signals when the spectral measurement starts. Unfortunately no information about input mode.

Quoted 8 lines

There is no separate control? If so we can't use it as a GPIO as whilst there is a control to set the state it will randomly get overwritten if we do such a read. So to me sounds like that is there for testing the connection and similar usecases only and we should not expose this as a GPIO. Maybe input is possible but that may also have side effects. So I'd be tempted to drop it from the binding - with some description of why it is not there in the patch description.

Agreed. What does this mean for the LED then? For all intents and purposes it's controlled by only 1 register. It may have some interactions with the GPIO but since they are completely undocumented so we might as well consider them non-existent. IMO it probably doesn't warrant a LED subnode and led-max-microamp is enough. Maybe DT folks can also comment on that.

Quoted 14 lines

Quoted 13 lines

Quoted 12 lines

Quoted 10 lines

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +8 -0

+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+
+additionalProperties: false    

Quoted 50 lines · On Sat, 12 Sep 2026 20:20:13 -0700 Chang Yu <[email protected]> wrote:

Quoted 40 lines · Jonathan Cameron

Quoted 28 lines · On Sat, 12 Sep 2026 18:35:14 -0700 Chang Yu <[email protected]> wrote:

Hi Jonathan,

A quick comment inline.

Quoted 16 lines · Jonathan Cameron

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 45

Quoted 12 lines · On Fri, 11 Sep 2026 18:39:11 -0700 Chang Yu <[email protected]> wrote:

Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +12 -0

+    description:
+      The driver current for the external LED connected to the LDR pin.
+    minimum: 4000
+    maximum: 258000
+    multipleOf: 2000
+    default: 12000
+
+  sync-gpios:
+    description: |
+      Optional GPIO pin that can be used either as a synchronization input to
+      start/stop measurement or as an external start/stop signal for
+      synchronizing with the connected LED.    

Quoted 7 lines

So the datasheet starts referring to using this for some level of sync but then only actually treats it as as a gpio (maybe I'm missing something). Any idea what that stuff about start/stop is talking about?

The only thing I can find about this is the device diagram in figure 13 that has the GPIO wired to the led driver and the automatic measurement engine.

Quoted 8 lines

That's what I got from the datasheet as well. They don't describe how to use the GPIO pin to perform synchronizations at all.

The adafruit arduino driver
(https://github.com/adafruit/Adafruit_AS7343/blob/main/Adafruit_AS7343.cpp)
is slightly more helpful - the GPIO in output mode signals when the spectral measurement starts. Unfortunately no information about input mode.

Quoted 8 lines

There is no separate control? If so we can't use it as a GPIO as whilst there is a control to set the state it will randomly get overwritten if we do such a read. So to me sounds like that is there for testing the connection and similar usecases only and we should not expose this as a GPIO. Maybe input is possible but that may also have side effects. So I'd be tempted to drop it from the binding - with some description of why it is not there in the patch description.

Quoted 5 lines

Agreed. What does this mean for the LED then? For all intents and purposes it's controlled by only 1 register. It may have some interactions with the GPIO but since they are completely undocumented so we might as well consider them non-existent. IMO it probably doesn't warrant a LED subnode and led-max-microamp is enough. Maybe DT folks can also comment on that.

Agreed, given software is controlling the current we need that and there isn't a lot more we can do. I guess you have the Adafruit board. Are the pins wired out so you can perhaps see what happens in practice?

Add a driver for the AMS AS7343 14-channel multi-spectral sensor.

The AS7343 is a 14-channel spectral sensor featuring 11 visible channels, 1 near-infrared channel, 1 clear channel (VIS), and 1 flicker detection channel.

The driver exposes 12 spectral channels (11 visible light and 1 near-infrared) via sysfs. Runtime PM is implemented to stop measurements when the device is suspended or torn down. Power is never cut (PON=1 always) to preserve register values.

Future patches will add configurable gain and integration time, interrupt support, buffered reads, VIS channel, and flicker detection.

Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf

Signed-off-by Chang Yu <[email protected]>

drivers/iio/light/as7343.c new file +27 -0

+
+#define AS7343_CFG0				0xbf
+#define AS7343_CFG0_REG_BANK			BIT(4)
+
+#define AS7343_CFG1				0xc6
+#define AS7343_CFG1_AGAIN			GENMASK(4, 0)
+#define AS7343_CFG1_AGAIN_X0_5			0
+#define AS7343_CFG1_AGAIN_X1			1
+#define AS7343_CFG1_AGAIN_X2			2
+#define AS7343_CFG1_AGAIN_X4			3
+#define AS7343_CFG1_AGAIN_X8			4
+#define AS7343_CFG1_AGAIN_X16			5
+#define AS7343_CFG1_AGAIN_X32			6
+#define AS7343_CFG1_AGAIN_X64			7
+#define AS7343_CFG1_AGAIN_X128			8
+#define AS7343_CFG1_AGAIN_X256			9
+#define AS7343_CFG1_AGAIN_X512			10
+#define AS7343_CFG1_AGAIN_X1024			11
+#define AS7343_CFG1_AGAIN_X2048			12
+
+#define AS7343_CFG20				0xd6
+#define AS7343_CFG20_AUTO_SMUX			GENMASK(6, 5)
+#define AS7343_CFG20_AUTO_SMUX_READOUT_ALL	3 /* all-channel readout */
+
+#define AS7343_CONTROL				0xfa
+
+/* AS7343 status registers */

drivers/iio/light/as7343.c new file +51 -0

+#define AS7343_DATA_FY		0x97
+#define AS7343_DATA_FXL		0x99
+#define AS7343_DATA_NIR		0x9b
+#define AS7343_DATA_F2		0xa1
+#define AS7343_DATA_F3		0xa3
+#define AS7343_DATA_F4		0xa5
+#define AS7343_DATA_F6		0xa7
+#define AS7343_DATA_F1		0xad
+#define AS7343_DATA_F7		0xaf
+#define AS7343_DATA_F8		0xb1
+#define AS7343_DATA_F5		0xb3
+#define AS7343_DATA_FD_L	0xb7
+#define AS7343_DATA_FD_H	0xb8
+
+/* AS7343 FIFO buffer data registers */
+#define AS7343_FIFO_LVL		0xfd
+#define AS7343_FDATA_L		0xfe
+#define AS7343_FDATA_H		0xff
+
+/* AS7343 channel indices. MUST match data register order above. */
+#define AS7343_CHAN_IDX_FZ	0
+#define AS7343_CHAN_IDX_FY	1
+#define AS7343_CHAN_IDX_FXL	2
+#define AS7343_CHAN_IDX_NIR	3
+#define AS7343_CHAN_IDX_F2	4
+#define AS7343_CHAN_IDX_F3	5
+#define AS7343_CHAN_IDX_F4	6
+#define AS7343_CHAN_IDX_F6	7
+#define AS7343_CHAN_IDX_F1	8
+#define AS7343_CHAN_IDX_F7	9
+#define AS7343_CHAN_IDX_F8	10
+#define AS7343_CHAN_IDX_F5	11
+
+#define AS7343_CHAN(_chan)					\
+	{							\
+		.type = IIO_INTENSITY,				\
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),	\
+		.address = AS7343_DATA_##_chan,			\
+		.indexed = 1,					\
+		.channel = AS7343_CHAN_IDX_##_chan,		\
+	}
+
+static const struct iio_chan_spec as7343_channels[] = {
+	AS7343_CHAN(FZ), AS7343_CHAN(FY), AS7343_CHAN(FXL), AS7343_CHAN(NIR),
+	AS7343_CHAN(F2), AS7343_CHAN(F3), AS7343_CHAN(F4),  AS7343_CHAN(F6),
+	AS7343_CHAN(F1), AS7343_CHAN(F7), AS7343_CHAN(F8),  AS7343_CHAN(F5),
+};
+
+struct as7343_data {
+	struct regmap *regmap;
+	/* Ensures reads don't stomp on each other */

drivers/iio/light/as7343.c new file +34 -0

+				       &result, sizeof(result));
+		if (ret)
+			return ret;
+
+		*val = le16_to_cpu(result);
+		return IIO_VAL_INT;
+	}
+
+	default:
+		return -EINVAL;
+	}
+}
+
+/*
+ * Channel names and wavelength ranges as defined in the datasheet
+ * (Figure 7, "AS7343 Optical Channel Summary"). Values are the
+ * minimum and maximum peak wavelength in nanometers.
+ *
+ * F1:  395-415 nm
+ * F2:  415-435 nm
+ * FZ:  440-460 nm
+ * F3:  465-485 nm
+ * F4:  505-525 nm
+ * FY:  545-565 nm
+ * F5:  540-560 nm
+ * FXL: 590-610 nm
+ * F6:  630-650 nm
+ * F7:  680-700 nm
+ * F8:  735-755 nm
+ * NIR: 845-865 nm
+ */
+static const char * const as7343_channel_labels[] = {
+	[AS7343_CHAN_IDX_F1] = "F1",
+	[AS7343_CHAN_IDX_F2] = "F2",

drivers/iio/light/as7343.c new file +11 -0

+
+	if (channel >= ARRAY_SIZE(as7343_channel_labels))
+		return -EINVAL;
+
+	return sysfs_emit(label, "%s\n", as7343_channel_labels[channel]);
+}
 
+
+static int as7343_setup_device(struct device *dev, struct as7343_data *data)
+{
+	struct regmap *map = data->regmap;
+	unsigned int val;

drivers/iio/light/as7343.c new file +4 -0

+	if (ret)
+		return ret;
+
+	return regmap_update_bits(map, AS7343_CFG1, AS7343_CFG1_AGAIN,

drivers/iio/light/as7343.c new file +4 -0

+}
+
+static int as7343_probe(struct i2c_client *client)
+{

drivers/iio/light/as7343.c new file +5 -0

+	if (ret)
+		return ret;
+
+	return devm_iio_device_register(dev, indio_dev);
+}

drivers/iio/light/as7343.c line 154

Quoted 7 lines · On Fri, 11 Sep 2026 18:39:12 -0700 Chang Yu <[email protected]> wrote:

drivers/iio/light/as7343.c new file +7 -0

+static int as7343_read_raw(struct iio_dev *indio_dev,
+			   struct iio_chan_spec const *chan,
+			   int *val, int *val2, long mask)
+{
+	struct as7343_data *data = iio_priv(indio_dev);
+	unsigned int unused;
+	struct regmap *map;

	struct regmap *map = data->regmap;
	struct device *dev = regmap_get_device(map);

Neither is checked so no point in waiting until a few lines later to initialize them.

...

drivers/iio/light/as7343.c line 175

Quoted 13 lines

drivers/iio/light/as7343.c new file +13 -0

+	ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+	if (ret)
+		return ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW: {
+		/* Wait until integration time passes for all 3 cycles. */
+		msleep(160);
+
+		/*
+		 * Reading ASTATUS latches all data registers to this read.
+		 * We don't care about the returned saturation/gain status for
+		 * now.

Why do we care given only reading one channel and...

drivers/iio/light/as7343.c line 182

Quoted 7 lines

drivers/iio/light/as7343.c new file +7 -0

+		 */
+		guard(mutex)(&data->mutex);
+		ret = regmap_read(map, AS7343_ASTATUS, &unused);
+		if (ret)
+			return ret;
+
+		ret = regmap_bulk_read(map, chan->address,

.. it seems that if you read the low byte first (as this does) it is latched anyway. There is a statement about this in the i2c intro part section 9.

so we get a consistent register pair. Thus not needing the latch astatus gives us.
With that in place reads can't stomp on each other as only one regmap read is required, so the mutex isn't needed either. It may be necessary once you add more features - hard to tell yet.

Quoted 12 lines · Jonathan Cameron

drivers/iio/light/as7343.c line 154

Quoted 7 lines · On Fri, 11 Sep 2026 18:39:12 -0700 Chang Yu <[email protected]> wrote:

drivers/iio/light/as7343.c new file +7 -0

+static int as7343_read_raw(struct iio_dev *indio_dev,
+			   struct iio_chan_spec const *chan,
+			   int *val, int *val2, long mask)
+{
+	struct as7343_data *data = iio_priv(indio_dev);
+	unsigned int unused;
+	struct regmap *map;  

	struct regmap *map = data->regmap;
	struct device *dev = regmap_get_device(map);

Quoted 3 lines

Neither is checked so no point in waiting until a few lines later to initialize them.

I was trying to preserve the reverse christmas tree order and was unsure how the rules apply here. Is the following OK:

  struct as7343_data *data = iio_priv(indio_dev);
  struct regmap *map = data->regmap;
  struct device *dev = regmap_get_device(map);

struct device *dev;
__le16 result;
int ret;

Quoted 28 lines

...

drivers/iio/light/as7343.c line 175

Quoted 13 lines

drivers/iio/light/as7343.c new file +13 -0

+	ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+	if (ret)
+		return ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW: {
+		/* Wait until integration time passes for all 3 cycles. */
+		msleep(160);
+
+		/*
+		 * Reading ASTATUS latches all data registers to this read.
+		 * We don't care about the returned saturation/gain status for
+		 * now.  

Why do we care given only reading one channel and...

drivers/iio/light/as7343.c line 182

Quoted 7 lines

drivers/iio/light/as7343.c new file +7 -0

+		 */
+		guard(mutex)(&data->mutex);
+		ret = regmap_read(map, AS7343_ASTATUS, &unused);
+		if (ret)
+			return ret;
+
+		ret = regmap_bulk_read(map, chan->address,  

.. it seems that if you read the low byte first (as this does) it is latched anyway. There is a statement about this in the i2c intro part section 9.

Quoted 6 lines

so we get a consistent register pair. Thus not needing the latch astatus gives us.
With that in place reads can't stomp on each other as only one regmap read is required, so the mutex isn't needed either. It may be necessary once you add more features - hard to tell yet.

When testing on hardware I discovered, for whatever reason, register values for other channels won't refresh unless I read ASTATUS or the FZ channel first. The only thing I can find in the datasheet pertaining to this is 10.2.7 page 41.

"Reading the ASTATUS register (0x94) latches all 36 spectral data bytes to that status read. Reading these bytes consecutively (0x94 to 0xB8) ensures that the data is concurrent."

My most charitable interpretation is that by "latches" they also mean "updates". I have no idea why reading FZ also works though. Could be a hardware bug since ASTATUS (0x94) and FZ DATA_0_L (0x95) are next to each other.

Add a driver for the AMS AS7343 14-channel multi-spectral sensor.

The AS7343 is a 14-channel spectral sensor featuring 11 visible channels, 1 near-infrared channel, 1 clear channel (VIS), and 1 flicker detection channel.

The driver exposes 12 spectral channels (11 visible light and 1 near-infrared) via sysfs. Runtime PM is implemented to stop measurements when the device is suspended or torn down. Power is never cut (PON=1 always) to preserve register values.

Future patches will add configurable gain and integration time, interrupt support, buffered reads, VIS channel, and flicker detection.

+/*
+ * Support for AMS AS7343 14-channel multi-spectral sensor.
+ * (7-bit I2C slave address 0x39)
+ *
+ * Based on the work of:
+ * Christian Eggers <[email protected]> (AS73211 driver)
+ *
+ * Copyright (c) 2026 Chang Yu <[email protected]>
+ *
+ * Datasheets:

+ * https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
+ *
+ * TODO:

+ *   - Autosuspend
+ *   - Support for configurable gain and integration time
+ *   - Interrupt support
+ *   - Add support for reading the VIS channel
+ *   - Flicker detection

+ */

drivers/iio/light/as7343.c new file +30 -0

+#define AS7343_ID				0x5a
 
+/* AS7343 config registers */
+#define AS7343_ENABLE				0x80
 
+#define AS7343_ATIME				0x81
 
+#define AS7343_ASTEP				0xd4
 
 
+#define AS7343_CFG0				0xbf
+
+#define AS7343_CFG1				0xc6
 
+#define AS7343_CFG20				0xd6
 
+#define AS7343_CONTROL				0xfa
+
+/* AS7343 status registers */
+#define AS7343_STATUS2				0x90
+#define AS7343_STATUS3				0x91
+#define AS7343_STATUS				0x93
+#define AS7343_ASTATUS				0x94
+#define AS7343_STATUS5				0xbb
+#define AS7343_STATUS4				0xbc
+#define AS7343_FD_STATUS			0xe3
+
+/* AS7343 spectral data registers */
+#define AS7343_DATA_FZ		0x95
+#define AS7343_DATA_FY		0x97
+#define AS7343_DATA_FXL		0x99
+#define AS7343_DATA_NIR		0x9b
+#define AS7343_DATA_F2		0xa1
+#define AS7343_DATA_F3		0xa3
+#define AS7343_DATA_F4		0xa5
+#define AS7343_DATA_F6		0xa7
+#define AS7343_DATA_F1		0xad

drivers/iio/light/as7343.c new file +6 -0

+	PM_RUNTIME_ACQUIRE_IF_ENABLED(dev, pm);
+	ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+	if (ret)
+		return ret;
+
+	switch (mask) {

drivers/iio/light/as7343.c new file +17 -0

+		ret = regmap_read(map, AS7343_ASTATUS, &unused);
+		if (ret)
+			return ret;
+
+		ret = regmap_bulk_read(map, chan->address,
+				       &result, sizeof(result));
+		if (ret)
+			return ret;
+
+		*val = le16_to_cpu(result);
+		return IIO_VAL_INT;
+	}
+
+	default:
+		return -EINVAL;
+	}
+}

drivers/iio/light/as7343.c new file +13 -0

+static int as7343_setup_device(struct device *dev, struct as7343_data *data)
+{
+	struct regmap *map = data->regmap;
+	unsigned int val;
+	__le16 step;
+	int ret;
+
+	/* Power on */
+	ret = regmap_set_bits(map, AS7343_ENABLE, AS7343_ENABLE_PON);
+	if (ret)
+		return ret;
+
+	/* Need to set REG_BANK to 1 before we can access ID */

drivers/iio/light/as7343.c new file +25 -0

+	ret = regmap_clear_bits(map, AS7343_CFG0, AS7343_CFG0_REG_BANK);
+	if (ret)
+		return ret;
+
+	/* Configure the SMUX to readout all channels */
+	ret = regmap_update_bits(map, AS7343_CFG20, AS7343_CFG20_AUTO_SMUX,
+				 FIELD_PREP(AS7343_CFG20_AUTO_SMUX,
+					    AS7343_CFG20_AUTO_SMUX_READOUT_ALL));
+	if (ret)
+		return ret;
+
+	/* Set 50.1ms integration time and x256 gain for now */
+	step = cpu_to_le16(AS7343_ASTEP_VAL);
+	ret = regmap_bulk_write(map, AS7343_ASTEP, &step, sizeof(step));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(map, AS7343_ATIME, AS7343_ATIME_VAL);
+	if (ret)
+		return ret;
+
+	return regmap_update_bits(map, AS7343_CFG1, AS7343_CFG1_AGAIN,
+				  FIELD_PREP(AS7343_CFG1_AGAIN,
+					     AS7343_CFG1_AGAIN_X256));
+}

(quoted diff) +2 -0

+	as7343_suspend(dev);
+}

On Fri, Sep 11, 2026 at 06:39:12PM -0700, Chang Yu wrote:

...

Quoted 20 lines

drivers/iio/light/as7343.c new file +20 -0

+static int as7343_setup_device(struct device *dev, struct as7343_data *data)
+{
+	struct regmap *map = data->regmap;
+	unsigned int val;
+	__le16 step;
+	int ret;
+
+	/* Power on */
+	ret = regmap_set_bits(map, AS7343_ENABLE, AS7343_ENABLE_PON);
+	if (ret)
+		return ret;
+
+	/* Need to set REG_BANK to 1 before we can access ID */
+	ret = regmap_set_bits(map, AS7343_CFG0, AS7343_CFG0_REG_BANK);
+	if (ret)
+		return ret;
+
+	ret = regmap_read(map, AS7343_ID, &val);
+	if (ret)
+		return ret;

drivers/iio/light/as7343.c line 292

Quoted 2 lines

drivers/iio/light/as7343.c new file +2 -0

+	if (val != 0x81)
+		dev_info(dev, "Unknown device ID: %x\n", val);

Wouldn't be better to define 0x81 with meaningful name?

Quoted 25 lines

drivers/iio/light/as7343.c new file +25 -0

+	ret = regmap_clear_bits(map, AS7343_CFG0, AS7343_CFG0_REG_BANK);
+	if (ret)
+		return ret;
+
+	/* Configure the SMUX to readout all channels */
+	ret = regmap_update_bits(map, AS7343_CFG20, AS7343_CFG20_AUTO_SMUX,
+				 FIELD_PREP(AS7343_CFG20_AUTO_SMUX,
+					    AS7343_CFG20_AUTO_SMUX_READOUT_ALL));
+	if (ret)
+		return ret;
+
+	/* Set 50.1ms integration time and x256 gain for now */
+	step = cpu_to_le16(AS7343_ASTEP_VAL);
+	ret = regmap_bulk_write(map, AS7343_ASTEP, &step, sizeof(step));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(map, AS7343_ATIME, AS7343_ATIME_VAL);
+	if (ret)
+		return ret;
+
+	return regmap_update_bits(map, AS7343_CFG1, AS7343_CFG1_AGAIN,
+				  FIELD_PREP(AS7343_CFG1_AGAIN,
+					     AS7343_CFG1_AGAIN_X256));
+}

...

Quoted 5 lines

drivers/iio/light/as7343.c new file +5 -0

+static int as7343_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct as7343_data *data = iio_priv(indio_dev);
+	struct regmap *map = data->regmap;

drivers/iio/light/as7343.c line 326

Quoted 1 line

drivers/iio/light/as7343.c new file +1 -0

+	return regmap_clear_bits(map, AS7343_ENABLE, AS7343_ENABLE_SP_EN);

Can this mess up the raw read? If so, also needs a mutex to be held.

Quoted 1 line · Andy Shevchenko

On Fri, Sep 11, 2026 at 06:39:12PM -0700, Chang Yu wrote:

Quoted 4 lines

drivers/iio/light/as7343.c line 292

Quoted 2 lines

drivers/iio/light/as7343.c new file +2 -0

+	if (val != 0x81)
+		dev_info(dev, "Unknown device ID: %x\n", val);

Wouldn't be better to define 0x81 with meaningful name?

If I remeber correctly Jonathan prefers just putting 0x81 inline. I'm OK with either style so I'll defer to the judgement to Jonathan here.

Quoted 9 lines

drivers/iio/light/as7343.c line 326

Quoted 7 lines

drivers/iio/light/as7343.c new file +6 -0

+static int as7343_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct as7343_data *data = iio_priv(indio_dev);
+	struct regmap *map = data->regmap;
 
+	return regmap_clear_bits(map, AS7343_ENABLE, AS7343_ENABLE_SP_EN);

Can this mess up the raw read? If so, also needs a mutex to be held.

People familiar with runtime PM correct me if I'm wrong, but I believe PM_RUNTIME_ACQUIRE waits for any ongoing suspend callback to finish before returning? If so I think there is no risk of a race here. In the case of system suspend, worst case scenario SP_EN gets cleared before we read ASTATUS or the data register, which for my use case at least is OK since the entire system is suspending anyway.

Quoted 2 lines · Chang Yu

Quoted 1 line · Andy Shevchenko

On Fri, Sep 11, 2026 at 06:39:12PM -0700, Chang Yu wrote:

...

Quoted 10 lines

Quoted 9 lines

drivers/iio/light/as7343.c line 326

Quoted 7 lines

drivers/iio/light/as7343.c new file +6 -0

+static int as7343_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct as7343_data *data = iio_priv(indio_dev);
+	struct regmap *map = data->regmap;
 
+	return regmap_clear_bits(map, AS7343_ENABLE, AS7343_ENABLE_SP_EN);

Can this mess up the raw read? If so, also needs a mutex to be held.

Quoted 6 lines

People familiar with runtime PM correct me if I'm wrong, but I believe PM_RUNTIME_ACQUIRE waits for any ongoing suspend callback to finish before returning? If so I think there is no risk of a race here. In the case of system suspend, worst case scenario SP_EN gets cleared before we read ASTATUS or the data register, which for my use case at least is OK since the entire system is suspending anyway.

Yes, if the raw read is guarded. What about _setup()? Is it guaranteed to be free from races? If so, we are okay.

Quoted 25 lines · Andy Shevchenko

On Fri, Sep 11, 2026 at 06:39:12PM -0700, Chang Yu wrote:

...

Quoted 20 lines

drivers/iio/light/as7343.c new file +20 -0

+static int as7343_setup_device(struct device *dev, struct as7343_data *data)
+{
+	struct regmap *map = data->regmap;
+	unsigned int val;
+	__le16 step;
+	int ret;
+
+	/* Power on */
+	ret = regmap_set_bits(map, AS7343_ENABLE, AS7343_ENABLE_PON);
+	if (ret)
+		return ret;
+
+	/* Need to set REG_BANK to 1 before we can access ID */
+	ret = regmap_set_bits(map, AS7343_CFG0, AS7343_CFG0_REG_BANK);
+	if (ret)
+		return ret;
+
+	ret = regmap_read(map, AS7343_ID, &val);
+	if (ret)
+		return ret;  

Quoted 5 lines

drivers/iio/light/as7343.c line 292

Quoted 2 lines

drivers/iio/light/as7343.c new file +2 -0

+	if (val != 0x81)
+		dev_info(dev, "Unknown device ID: %x\n", val);  

Wouldn't be better to define 0x81 with meaningful name?

If I remeber correctly Jonathan prefers just putting 0x81 inline. I'm OK with either style so I'll defer to the judgement to Jonathan here.

Quoted 42 lines · Chang Yu

drivers/iio/light/as7343.c new file +35 -0

+#define AS7343_ID				0x5a
 
+/* AS7343 config registers */
+#define AS7343_ENABLE				0x80
 
+#define AS7343_ATIME				0x81
 
+#define AS7343_ASTEP				0xd4
 
 
+#define AS7343_CFG0				0xbf
+
+#define AS7343_CFG1				0xc6
 
+#define AS7343_CFG20				0xd6
 
+#define AS7343_CONTROL				0xfa
+
+/* AS7343 status registers */
+#define AS7343_STATUS2				0x90
+#define AS7343_STATUS3				0x91
+#define AS7343_STATUS				0x93
+#define AS7343_ASTATUS				0x94
+#define AS7343_STATUS5				0xbb
+#define AS7343_STATUS4				0xbc
+#define AS7343_FD_STATUS			0xe3
+
+/* AS7343 spectral data registers */
+#define AS7343_DATA_FZ		0x95
+#define AS7343_DATA_FY		0x97
+#define AS7343_DATA_FXL		0x99
+#define AS7343_DATA_NIR		0x9b
+#define AS7343_DATA_F2		0xa1
+#define AS7343_DATA_F3		0xa3
+#define AS7343_DATA_F4		0xa5
+#define AS7343_DATA_F6		0xa7
+#define AS7343_DATA_F1		0xad
+#define AS7343_DATA_F7		0xaf
+#define AS7343_DATA_F8		0xb1
+#define AS7343_DATA_F5		0xb3
+#define AS7343_DATA_FD_L	0xb7
+#define AS7343_DATA_FD_H	0xb8

drivers/iio/light/as7343.c line 111

Quoted 4 lines

drivers/iio/light/as7343.c new file +4 -0

+/* AS7343 FIFO buffer data registers */
+#define AS7343_FIFO_LVL		0xfd
+#define AS7343_FDATA_L		0xfe
+#define AS7343_FDATA_H		0xff

Please, keep indentation for the registers the same. Also would be nice to have them sorted by offset.

Quoted 1 line · Andy Shevchenko

On Fri, Sep 11, 2026 at 06:39:12PM -0700, Chang Yu wrote:

Quoted 8 lines

drivers/iio/light/as7343.c line 111

Quoted 4 lines

drivers/iio/light/as7343.c new file +4 -0

+/* AS7343 FIFO buffer data registers */
+#define AS7343_FIFO_LVL		0xfd
+#define AS7343_FDATA_L		0xfe
+#define AS7343_FDATA_H		0xff

Please, keep indentation for the registers the same. Also would be nice to have them sorted by offset.

Due to the register layout sometimes registers with similar functions/purposes are scattered across the address space. As a compromise I'll group registers by purposes and sort by offset within the same group.

This series adds initial support for the AMS AS7343 14-channel multi-spectral sensor.

The sensor has 14 optical channels (11 visible + NIR + clear + flicker) in total. This initial driver supports reading raw counts from all 12 spectral channels (11 visible + NIR) via sysfs and basic power management.

Not yet supported:
- Configurable integration time and gain
- Interrupt support
- Clear (VIS) channel and flicker detection

Patch 1 adds device tree bindings.
Patch 2 adds the driver.

Testing was performed on a Raspberry Pi 4.

Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf

Changes in v4:
- Fix led-max-microamp property in dt bindings.
- Use REGCACHE_MAPLE and add volatile table.
- Use PM_RUNTIME_ACQUIRE* when resuming.

Changes in v3:
- Fix gpio description and example in dt.
- Only start measurements after suspend action has been registered.
- Add a mutex and pm_runtime_resume_and_get before reading measurements.

Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the dt bindings.
- Adjust the default gain to x256 and integration time to 50.1ms as recommended by the datasheet.
- Use read_label instead of .extend
- Remove all unused scan_index related constants.

Chang Yu (2):
dt-bindings: iio: light: add as7343
iio: light: add AS7343 multi-spectral sensor driver

 .../bindings/iio/light/ams,as7343.yaml        |  72 +++
 MAINTAINERS                                   |   7 +
 drivers/iio/light/Kconfig                     |  11 +
 drivers/iio/light/Makefile                    |   1 +
 drivers/iio/light/as7343.c                    | 434 ++++++++++++++++++
 5 files changed, 525 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yaml
 create mode 100644 drivers/iio/light/as7343.c

Quoted 7 lines · On Fri, 11 Sep 2026 18:39:10 -0700 Chang Yu <[email protected]> wrote:

This series adds initial support for the AMS AS7343 14-channel multi-spectral sensor.

The sensor has 14 optical channels (11 visible + NIR + clear + flicker) in total. This initial driver supports reading raw counts from all 12 spectral channels (11 visible + NIR) via sysfs and basic power management.

Hi Chang Yu,

We all appreciate enthusiasm but...

No idea if anyone called it out already but please slow down. Typically reviewers only get to looking at IIO patches once every week or so (in totality - they may review a few random ones more often whilst waiting for something to happen).

So for a driver in early stages of review, once a week at most for new versions. That way we consolidate a bunch of feedback. Key thing is many folk looking at your code doe enough review that they don't have the previous version in their head so each very takes roughly the same amount of time to do - it doesn't get shorter until very near merging when we know tiny stuff only is changing.

Jonathan

Quoted 43 lines

Not yet supported:
- Configurable integration time and gain
- Interrupt support
- Clear (VIS) channel and flicker detection

Patch 1 adds device tree bindings.
Patch 2 adds the driver.

Testing was performed on a Raspberry Pi 4.

Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf

Changes in v4:
- Fix led-max-microamp property in dt bindings.
- Use REGCACHE_MAPLE and add volatile table.
- Use PM_RUNTIME_ACQUIRE* when resuming.

Changes in v3:
- Fix gpio description and example in dt.
- Only start measurements after suspend action has been registered.
- Add a mutex and pm_runtime_resume_and_get before reading measurements.

Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the dt bindings.
- Adjust the default gain to x256 and integration time to 50.1ms as recommended by the datasheet.
- Use read_label instead of .extend
- Remove all unused scan_index related constants.

Chang Yu (2):
dt-bindings: iio: light: add as7343
iio: light: add AS7343 multi-spectral sensor driver

 .../bindings/iio/light/ams,as7343.yaml        |  72 +++
 MAINTAINERS                                   |   7 +
 drivers/iio/light/Kconfig                     |  11 +
 drivers/iio/light/Makefile                    |   1 +
 drivers/iio/light/as7343.c                    | 434 ++++++++++++++++++
 5 files changed, 525 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yaml
 create mode 100644 drivers/iio/light/as7343.c