Add support for AS7343 multi-spectral sensor
Subsystems (2)
v2 cover Add support for AS7343 multi-spectral sensor
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 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 | 69 ++++ MAINTAINERS | 7 + drivers/iio/light/Kconfig | 11 + drivers/iio/light/Makefile | 1 + drivers/iio/light/as7343.c | 372 ++++++++++++++++++ 5 files changed, 460 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yaml create mode 100644 drivers/iio/light/as7343.c
Signature · 1 line
2.55.0
PATCH v2 1/2 dt-bindings: iio: light: add as7343
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of 0x39.
The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- Include MAINTAINERS changes.
.../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yaml
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +69 -0
@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1 + + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000 + + gpios: + description: + Optional GPIO pin for general I/O. + maxItems: 1 + +required: + - compatible + - reg + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + multispectral-sensor@39 { + compatible = "ams,as7343"; + reg = <0x39>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vdd_regulator>; + ams,led-current-microamp = <14000>; + gpios = <&gpio0 6 GPIO_ACTIVE_LOW>; + }; + };
MAINTAINERS +6 -0
@@ -1430,6 +1430,12 @@ S: Maintained F: Documentation/devicetree/bindings/iio/light/ams,as73211.yaml F: drivers/iio/light/as73211.c +AMS AS7343 DRIVER +M: Chang Yu <[email protected]> +L: [email protected] +S: Maintained +F: Documentation/devicetree/bindings/iio/light/ams,as7343.yaml + AMT (Automatic Multicast Tunneling) M: Taehee Yoo <[email protected]> L: [email protected]
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Missing `#include <dt-bindings/gpio/gpio.h>` for `GPIO_ACTIVE_LOW` in the dt-binding example. --
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing #include <dt-bindings/gpio/gpio.h> for GPIO_ACTIVE_LOW in the dt-binding example. --
commit 6fee3afaa3c4f47b1efbffef07588793c6bc1b7e
Author: Chang Yu <[email protected]>
dt-bindings: iio: light: add as7343
This commit adds a new device tree binding for the AMS AS7343 14-channel multi-spectral sensor.
Quoted 5 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +0
-0
[ ... ]
Quoted 5 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +5
-0+examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c {
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 67
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ #address-cells = <1>; + #size-cells = <0>; + + multispectral-sensor@39 { + compatible = "ams,as7343"; + reg = <0x39>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vdd_regulator>; + ams,led-current-microamp = <14000>; + gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
[Severity: Low]
Does this examples block need to include <dt-bindings/gpio/gpio.h>?
This gpios assignment relies on the GPIO_ACTIVE_LOW macro. Without the corresponding header included at the top of the examples block, the dtc compiler will fail with a syntax error during make dt_binding_check because the unexpanded macro will be treated as an invalid token inside the cell array.
Quoted 2 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +2
-0+ }; + };
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Re: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
In reply to Chang YuQuoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Quoted 49 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000
Rather than a custom property, the tsl2772 uses led-max-microamp:tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 43
Quoted 4 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +4
-0+ + gpios: + description: + Optional GPIO pin for general I/O.
Please expand on "general IO". Docs appear to suggest this is used for synchronisation.
Additionally, I think this name will make the gpio somewhat difficult to request. Calling it "sync-gpios" or w/e will permit the usual gpiod functions being used.
Quoted 14 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +14
-0+ maxItems: 1 + +required: + - compatible + - reg + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c {
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 67
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ #address-cells = <1>; + #size-cells = <0>; + + multispectral-sensor@39 { + compatible = "ams,as7343"; + reg = <0x39>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vdd_regulator>; + ams,led-current-microamp = <14000>; + gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
Valid Sashiko comment here I believe.
pw-bot: changes-requested
Thanks,
Conor.
Quoted 22 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +2
-0+ }; + };MAINTAINERS +6
-0@@ -1430,6 +1430,12 @@ S: Maintained F: Documentation/devicetree/bindings/iio/light/ams,as73211.yaml F: drivers/iio/light/as73211.c +AMS AS7343 DRIVER +M: Chang Yu <[email protected]> +L: [email protected] +S: Maintained +F: Documentation/devicetree/bindings/iio/light/ams,as7343.yaml + AMT (Automatic Multicast Tunneling) M: Taehee Yoo <[email protected]> L: [email protected]Signature · 1 line
2.55.0
Jonathan Cameron
maintainerRe: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Quoted 65 lines
Quoted 49 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;
Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the leds/common.yaml definition of led-max-microamp?
Thanks,
Jonathan
Re: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 64 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;
Quoted 8 lines
Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?
Could always just put a ref in to leds/common.yaml and not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.
Cheers,
Conor.
Jonathan Cameron
maintainerRe: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 101 lines · On Tue, 15 Sep 2026 18:11:17 +0100 Conor Dooley <[email protected]> wrote:
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 64 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;Quoted 8 lines
Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?
Quoted 5 lines
Could always just put a ref in to
leds/common.yamland not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.
Sounds good to me.
Quoted 2 lines
Cheers,
Conor.
Re: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 104 lines · Jonathan Cameron
Quoted 101 lines · On Tue, 15 Sep 2026 18:11:17 +0100 Conor Dooley <[email protected]> wrote:
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 72 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?
Quoted 10 lines
Quoted 5 lines
Could always just put a ref in to
leds/common.yamland not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.Sounds good to me.
Quoted 2 lines
Cheers,
Conor.
A quick heads up, adding a ref produces the following error when running dt_binding_check:
properties:led-max-microamp: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref from schema $id: http://devicetree.org/meta-schemas/core.yaml
So it looks like we can just put led-max-microamp, and not add the $ref.
Jonathan Cameron
maintainerRe: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 115 lines · On Fri, 18 Sep 2026 18:55:00 -0700 Chang Yu <[email protected]> wrote:
Quoted 104 lines · Jonathan Cameron
Quoted 101 lines · On Tue, 15 Sep 2026 18:11:17 +0100 Conor Dooley <[email protected]> wrote:
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 72 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?Quoted 10 lines
Quoted 5 lines
Could always just put a ref in to
leds/common.yamland not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.Sounds good to me.
Quoted 2 lines
Cheers,
Conor.
Quoted 8 lines
A quick heads up, adding a ref produces the following error when running
dt_binding_check:properties:led-max-microamp: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref from schema $id: http://devicetree.org/meta-schemas/core.yamlSo it looks like we can just put led-max-microamp, and not add the $ref.
Ah. That's a bit irritating as it is assuming the ref is to get the type rather than to make the connection to the standard definition of what it is. Conor, what is the best way around this? Maybe a comment to say where it is documented instead of a $ref?
J
Re: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 125 lines · Jonathan Cameron
Quoted 122 lines · On Fri, 18 Sep 2026 18:55:00 -0700 Chang Yu <[email protected]> wrote:
Quoted 104 lines · Jonathan Cameron
Quoted 101 lines · On Tue, 15 Sep 2026 18:11:17 +0100 Conor Dooley <[email protected]> wrote:
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 72 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?Quoted 10 lines
Quoted 5 lines
Could always just put a ref in to
leds/common.yamland not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.Sounds good to me.
Quoted 2 lines
Cheers,
Conor.A quick heads up, adding a ref produces the following error when running
dt_binding_check:properties:led-max-microamp: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref from schema $id: http://devicetree.org/meta-schemas/core.yaml
Quoted 6 lines
Quoted 1 line
So it looks like we can just put led-max-microamp, and not add the $ref.
Ah. That's a bit irritating as it is assuming the ref is to get the type rather than to make the connection to the standard definition of what it is. Conor, what is the best way around this? Maybe a comment to say where it is documented instead of a $ref?
From the error, it looks like this was done incorrectly, but impossible to tell for sure without the snippet. The ref I was talking about would be at the top level
Quoted 3 lines
J
Re: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 130 lines · Conor
Quoted 127 lines · Jonathan Cameron
Quoted 123 lines · On Fri, 18 Sep 2026 18:55:00 -0700 Chang Yu <[email protected]> wrote:
Quoted 104 lines · Jonathan Cameron
Quoted 101 lines · On Tue, 15 Sep 2026 18:11:17 +0100 Conor Dooley <[email protected]> wrote:
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 72 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?Quoted 10 lines
Quoted 5 lines
Could always just put a ref in to
leds/common.yamland not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.Sounds good to me.
Quoted 2 lines
Cheers,
Conor.A quick heads up, adding a ref produces the following error when running
dt_binding_check:properties:led-max-microamp: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref from schema $id: http://devicetree.org/meta-schemas/core.yamlSo it looks like we can just put led-max-microamp, and not add the $ref.
Quoted 11 lines
Quoted 4 lines
Ah. That's a bit irritating as it is assuming the ref is to get the type rather than to make the connection to the standard definition of what it is. Conor, what is the best way around this? Maybe a comment to say where it is documented instead of a $ref?
From the error, it looks like this was done incorrectly, but impossible to tell for sure without the snippet. The ref I was talking about would be at the top level
Quoted 3 lines
J
I was doing something like:
led-max-microamp:
$ref: /schemas/leds/common.yaml#/properties/led-max-microamp
minimum: 4000which gave me the error.
IIUC, Conor was suggesting something like:
allOf:
- $ref: /schemas/leds/common.yaml#
From my limited understanding of dt bindings, the above should not be used together with additionalProperties: false ? So do we want something like:
allOf:
- $ref: /schemas/leds/common.yaml#
unevaluatedProperties: false
Or just stick with what's in v5?
Re: [PATCH v2 1/2] dt-bindings: iio: light: add as7343
Quoted 146 lines · Chang Yu
Quoted 130 lines · Conor
Quoted 127 lines · Jonathan Cameron
Quoted 123 lines · On Fri, 18 Sep 2026 18:55:00 -0700 Chang Yu <[email protected]> wrote:
Quoted 104 lines · Jonathan Cameron
Quoted 101 lines · On Tue, 15 Sep 2026 18:11:17 +0100 Conor Dooley <[email protected]> wrote:
Quoted 21 lines · Jonathan Cameron
Quoted 10 lines · On Tue, 8 Sep 2026 19:13:55 +0100 Conor Dooley <[email protected]> wrote:
Quoted 6 lines · Chang Yu
Add binding for AMS AS7343 which is a 14-channel multi-spectral sensor with i2c address of
0x39.The GPIO pin is described as a generic GPIO for now. Binding design for the more advanced measurement/LED synchronization use cases are deferred to future patches.
Unfortunately, you can't change what you document, so picking something correct now is needed - even if the driver doesn't use it yet.
Definitely needs an outline of how it would be backwards compatible and an explanation of why not now. Sometimes a portion of the binding is so uncertain that we do kick it back from initial version but we 'must' be sure we can extend the binding to new configurations. Normally this is one of those we are fairly sure, but not entirely sure cases - or picking between two options where consensus isn't being reached.
Quoted 2 lines
Chang Yu: This sort of things needs discussion and is one of the reasons to go slowly.
Ye, I note that there are 2 more versions of this since I left this comment, but you seem to be on top of that.
Quoted 72 lines
Quoted 64 lines
Quoted 48 lines
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
Signed-off-by Chang Yu <[email protected]>---
Changes in v2:
- Add the LDR, the interrupt pin, and the GPIO pin to the bindings.
- Fix node name and unit address mismatch.
- IncludeMAINTAINERSchanges..../bindings/iio/light/ams,as7343.yaml | 69 +++++++++++++++++++ MAINTAINERS | 6 ++ 2 files changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/ams,as7343.yamlDocumentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +29
-0@@ -0,0 +1,69 @@ +# 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. + https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf + +properties: + compatible: + enum: + - ams,as7343 + + reg: + description: + I2C address of the device (0x39). + maxItems: 1 + + interrupts: + description: + Open drain output active low interrupt pin. + maxItems: 1Documentation/devicetree/bindings/iio/light/ams,as7343.yaml line 39
Quoted 10 lines
Documentation/devicetree/bindings/iio/light/ams,as7343.yaml new file +10
-0+ + vdd-supply: true + + ams,led-current-microamp: + description: + The driver current for the external LED connected to the LDR pin. + minimum: 4000 + maximum: 258000 + multipleOf: 2000 + default: 12000Rather than a custom property, the tsl2772 uses led-max-microamp:
tsl2772.yaml
46: led-max-microamp:
81: led-max-microamp = <100000>;Quoted 2 lines
I wonder if the same should be done here, or if there should be an leds subnode? Perhaps the IIO folks can comment on that.
I don't think we've ever bothered with a subnode as there only tends to be one of them. Given the enabling etc is all hardware controlled I'm not sure a more generic LED binding makes sense. I don't know that much about the led bindings though so maybe it is worth doing a subnode just to use the
leds/common.yamldefinition of led-max-microamp?Quoted 10 lines
Quoted 5 lines
Could always just put a ref in to
leds/common.yamland not bother with a child node. I'd stick with the additionalProperties: false, since there's lots of leds properties that probably don't apply to a device like this.Sounds good to me.
Quoted 2 lines
Cheers,
Conor.A quick heads up, adding a ref produces the following error when running
dt_binding_check:properties:led-max-microamp: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref from schema $id: http://devicetree.org/meta-schemas/core.yamlSo it looks like we can just put led-max-microamp, and not add the $ref.
Quoted 11 lines
Quoted 4 lines
Ah. That's a bit irritating as it is assuming the ref is to get the type rather than to make the connection to the standard definition of what it is. Conor, what is the best way around this? Maybe a comment to say where it is documented instead of a $ref?
From the error, it looks like this was done incorrectly, but impossible to tell for sure without the snippet. The ref I was talking about would be at the top level
Quoted 3 lines
J
I was doing something like:
led-max-microamp: $ref: /schemas/leds/common.yaml#/properties/led-max-microamp minimum: 4000
Quoted 8 lines
which gave me the error.
IIUC, Conor was suggesting something like:
allOf:
- $ref: /schemas/leds/common.yaml#From my limited understanding of dt bindings, the above should not be used together with additionalProperties: false ? So do we want something
It can be used with it, you just need to list the property in the schema you're writing - which you have to do anyway because you're setting constraints on it.
Cheers,
Conor
Quoted 9 lines
like:
allOf:
- $ref: /schemas/leds/common.yaml#unevaluatedProperties: false
Or just stick with what's in v5?
PATCH v2 2/2 iio: light: add AS7343 multi-spectral sensor driver
In reply to Chang YuThis patch adds a driver for the AMS AS7343 14-channel multi-spectral sensor with I2C interface.
The driver exposes 12 spectral channels (11 visible + 1 near-infrared) via the IIO sysfs interface. Each channel's raw data is provided as a 16-bit little-endian unsigned integer.
Basic power management (suspend/resume) is supported. More complex features such as auto-suspend, interrupts, and configurable gain/integration time will be added in future patches.
Datasheet: https://look.ams-osram.com/m/5f2d27fff9a874d2/original/AS7343-14-Channel-Multi-Spectral-Sensor.pdf
---
Changes in v2:
- 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.
- Add missing calls to pm_runtime_* methods in probe.
- Fix various code style issues
MAINTAINERS | 1 + drivers/iio/light/Kconfig | 11 ++ drivers/iio/light/Makefile | 1 + drivers/iio/light/as7343.c | 372 +++++++++++++++++++++++++++++++++++++ 4 files changed, 385 insertions(+) create mode 100644 drivers/iio/light/as7343.c
MAINTAINERS +1 -0
@@ -1435,6 +1435,7 @@ M: Chang Yu <[email protected]> L: [email protected] S: Maintained F: Documentation/devicetree/bindings/iio/light/ams,as7343.yaml +F: drivers/iio/light/as7343.c AMT (Automatic Multicast Tunneling) M: Taehee Yoo <[email protected]>
drivers/iio/light/Kconfig +11 -0
@@ -149,6 +149,17 @@ config AS73211 This driver can also be built as a module. If so, the module will be called as73211. +config AS7343 + tristate "AMS AS7343 14-Channel Multi-Spectral Sensor" + depends on I2C + select REGMAP_I2C + help + Say Y here to build support for the AMS AS7343 14-channel + multi-spectral sensor. + + To compile this driver as a module, choose M here: the module will + be called as7343. + config BH1745 tristate "ROHM BH1745 colour sensor" depends on I2C
drivers/iio/light/Makefile +1 -0
@@ -16,6 +16,7 @@ obj-$(CONFIG_APDS9306) += apds9306.o obj-$(CONFIG_APDS9960) += apds9960.o obj-$(CONFIG_APDS9999) += apds9999.o obj-$(CONFIG_AS73211) += as73211.o +obj-$(CONFIG_AS7343) += as7343.o obj-$(CONFIG_BH1745) += bh1745.o obj-$(CONFIG_BH1750) += bh1750.o obj-$(CONFIG_BH1780) += bh1780.o
drivers/iio/light/as7343.c new file +372 -0
372 lines not on this page · raw message
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 2/2] iio: light: add AS7343 multi-spectral sensor driver
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider: - [High] Device configuration is not restored on system resume, breaking the sensor if power is lost.…
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [High] Device configuration is not restored on system resume, breaking the sensor if power is lost.
- [Medium] The PM operations structure pointer is incorrectly wrapped with pm_sleep_ptr() instead of pm_ptr().
- [Medium] Missing PM runtime get/put in as7343_read_raw() allows reads while the device is runtime-suspended.
- [Medium] The variable 'val' is evaluated uninitialized when regmap_read() fails.
- [Medium] The device is left powered on during driver unbind and error paths.
- [Low] Incorrect base types used for endianness conversions cause Sparse warnings.
- [Low] Concurrent sysfs reads cause a race condition in as7343_read_raw() when latching and reading sensor data. --
commit b11536303f5757f091de7d446bfca2f105210812
Author: Chang Yu <[email protected]>
iio: light: add AS7343 multi-spectral sensor driver
This patch adds a driver for the AMS AS7343 14-channel multi-spectral sensor with I2C interface. It exposes 12 spectral channels via IIO sysfs and adds basic power management support.
Quoted 5 lines
drivers/iio/light/as7343.c new file +0
-0
[ ... ]
drivers/iio/light/as7343.c line 132
Quoted 8 lines
drivers/iio/light/as7343.c new file +8
-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); +int ret; +unsigned int unused; +u16 result;
[Severity: Low]
Do these assignments cause static analysis warnings with Sparse? 'result' is declared as u16 but assigned a __le16 value via regmap_bulk_read() and passed to le16_to_cpu() below.
drivers/iio/light/as7343.c line 141
Quoted 9 lines
drivers/iio/light/as7343.c new file +9
-0+ +switch (mask) { +case IIO_CHAN_INFO_RAW : { +/* +* Reading ASTATUS latches all data registers to this read. +* We don't care about the returned saturation/gain status for +* now. +*/ + ret =regmap_read (data->regmap,AS7343_ASTATUS , &unused);
[Severity: Medium]
Can this execute I2C reads against a suspended sensor?
The driver enables runtime PM which allows the device to be suspended (clearing the measurement enable bit). Reading raw data without waking the device using pm_runtime_resume_and_get() first could return stale or zero data.
[Severity: Low]
Can concurrent sysfs reads from different channels cause a race condition here?
The ASTATUS read latches all channels before the channel data is read. Without a lock, could interleaved reads result in one thread receiving data latched by another thread's ASTATUS read?
Quoted 10 lines
drivers/iio/light/as7343.c new file +10
-0+if (ret) +return ret; + + ret =regmap_bulk_read (data->regmap, chan->address, &result,2 ); +if (ret) +return ret; + + *val =le16_to_cpu (result); +return IIO_VAL_INT ; + }
[ ... ]
drivers/iio/light/as7343.c line 219
Quoted 4 lines
drivers/iio/light/as7343.c new file +4
-0+static int as7343_setup_device (struct device *dev,struct as7343_data *data) +{ +unsigned int val; +u16 step;
[Severity: Low]
Does this cause a strict typing warning with Sparse? 'step' is declared as u16 but receives a __le16 value via cpu_to_le16() below.
Quoted 5 lines
drivers/iio/light/as7343.c new file +5
-0+int ret; + +/* Power on */ + ret =regmap_set_bits (data->regmap,AS7343_ENABLE ,AS7343_ENABLE_PON ); +if (ret)
drivers/iio/light/as7343.c line 234
Quoted 10 lines
drivers/iio/light/as7343.c new file +10
-0+return ret; + +/* Need to set REG_BANK to 1 before we can access ID */ + ret =regmap_set_bits (data->regmap,AS7343_CFG0 ,AS7343_CFG0_REG_BANK ); +if (ret) +return ret; + + ret =regmap_read (data->regmap,AS7343_ID , &val); +if (val !=0x81 ) +dev_info (dev,"Unknown device ID: %x\n" , val);
[Severity: Medium]
If regmap_read() fails, it returns an error code and leaves the stack variable 'val' uninitialized. Could we be evaluating and printing uninitialized memory here since the error is ignored?
Quoted 3 lines
drivers/iio/light/as7343.c new file +3
-0+ + ret =regmap_clear_bits (data->regmap,AS7343_CFG0 , +AS7343_CFG0_REG_BANK );
[ ... ]
drivers/iio/light/as7343.c line 276
Quoted 7 lines
drivers/iio/light/as7343.c new file +7
-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); + +return regmap_clear_bits (data->regmap,AS7343_ENABLE , +AS7343_ENABLE_SP_EN );
[Severity: Medium]
Does this leave the device powered on indefinitely?
as7343_setup_device() sets the PON bit during probe, but this suspend action only clears SP_EN, meaning PON remains set when the device is unbound or suspended.
drivers/iio/light/as7343.c line 285
Quoted 9 lines
drivers/iio/light/as7343.c new file +9
-0+} + +static int as7343_resume (struct device *dev) +{ +struct iio_dev *indio_dev =dev_get_drvdata (dev); +struct as7343_data *data =iio_priv (indio_dev); + +return regmap_set_bits (data->regmap,AS7343_ENABLE , +AS7343_ENABLE_SP_EN );
[Severity: High]
Does this leave the sensor in a broken state after resuming from S3 sleep?
The driver uses REGCACHE_NONE, so all volatile configurations (gain, integration time, multiplexer) are lost when power to the sensor is lost. This resume function only sets the SP_EN bit without reinitializing the sensor's configuration.
Quoted 1 line
+}
[ ... ]
Quoted 2 lines
drivers/iio/light/as7343.c new file +2
-0+static int as7343_probe (struct i2c_client *client) +{
[ ... ]
drivers/iio/light/as7343.c line 327
Quoted 5 lines
drivers/iio/light/as7343.c new file +5
-0+ ret =as7343_setup_device (dev, data); +if (ret) +return ret; + + ret =devm_add_action_or_reset (dev, as7343_suspend_action, dev);
[Severity: Medium]
Does this leave the device powered on during error paths?
as7343_setup_device() powers on the device, but if a subsequent I2C operation in that function fails, this cleanup action is never registered, leaving the hardware powered on.
Quoted 3 lines
drivers/iio/light/as7343.c new file +3
-0+if (ret) +return dev_err_probe (dev, ret, +"Failed to add suspend action\n" );
[ ... ]
drivers/iio/light/as7343.c line 363
Quoted 5 lines
drivers/iio/light/as7343.c new file +5
-0+static struct i2c_driver as7343_driver = { + .driver = { + .name ="as7343" , + .of_match_table = as7343_of_match, + .pm =pm_sleep_ptr (&as7343_pm_ops),
[Severity: Medium]
Does this inadvertently drop runtime PM support when CONFIG_PM_SLEEP is disabled?
The dev_pm_ops structure defines runtime PM callbacks, but using pm_sleep_ptr() evaluates to NULL when CONFIG_PM_SLEEP=n, even if CONFIG_PM=y is set. Should this be wrapped with pm_ptr() instead?
Quoted 4 lines
drivers/iio/light/as7343.c new file +4
-0+ }, + .probe = as7343_probe, + .id_table = as7343_id, +};
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Re: [PATCH v2 2/2] iio: light: add AS7343 multi-spectral sensor driver
In reply to Chang YuHi Chang,
Please check out Sashiko's review, there are some PM runtime things that should be resolved + some comments inline.
https://sashiko.dev/#/patchset/20260907210042.32552-1-marcus.yu.56%40gmail.com
Thanks!
Josh
On Mon, 7 Sep 2026 14:00:42 -0700
Chang Yu <[email protected]> wrote:
...
drivers/iio/light/as7343.c line 32
Quoted 11 lines
drivers/iio/light/as7343.c new file +11
-0+#include <linux/array_size.h> +#include <linux/bitfield.h> +#include <linux/dev_printk.h> +#include <linux/err.h> +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/pm.h> +#include <linux/pm_runtime.h> +#include <linux/regmap.h> +#include <linux/regulator/consumer.h> +#include <linux/sysfs.h>
+ bits.h, types.h, <asm/byteorder.h> (asm headers go separately, as IIO headers).
Quoted 3 lines
drivers/iio/light/as7343.c new file +3
-0+ +#include <linux/iio/iio.h> +
...
Quoted 5 lines
drivers/iio/light/as7343.c new file +5
-0+struct as7343_data { +struct regmap *regmap; +}; + +static int as7343_read_raw(struct iio_dev *indio_dev,
drivers/iio/light/as7343.c line 135
Quoted 10 lines
drivers/iio/light/as7343.c new file +10
-0+ struct iio_chan_spec const *chan, int *val, + int *val2, long mask) +{ + struct as7343_data *data = iio_priv(indio_dev); +int ret; +unsigned int unused; +u16 result; + +switch (mask) { +case IIO_CHAN_INFO_RAW : {
The device should resume here, otherwise you'll be reading while suspended.
drivers/iio/light/as7343.c line 140
Quoted 5 lines
drivers/iio/light/as7343.c new file +5
-0+/* +* Reading ASTATUS latches all data registers to this read. +* We don't care about the returned saturation/gain status for +* now. +*/
Sashiko points out that a mutex here would come in handy. If you're going to add a mutex, use the guard(mutex) macro for automatic unlocking on scope exit.
Quoted 47 lines
drivers/iio/light/as7343.c new file +47
-0+ ret =regmap_read (data->regmap,AS7343_ASTATUS , &unused); +if (ret) +return ret; + + ret =regmap_bulk_read (data->regmap, chan->address, &result,2 ); +if (ret) +return ret; + + *val =le16_to_cpu (result); +return IIO_VAL_INT ; + } + +default : +return -EINVAL ; + } +} + +static const char *as7343_channel_label (struct iio_chan_spec const *chan) +{ +switch (chan->channel) { +case AS7343_CHAN_IDX_FZ : +return "FZ" ; +case AS7343_CHAN_IDX_FY : +return "FY" ; +case AS7343_CHAN_IDX_FXL : +return "FXL" ; +case AS7343_CHAN_IDX_NIR : +return "NIR" ; +case AS7343_CHAN_IDX_F2 : +return "F2" ; +case AS7343_CHAN_IDX_F3 : +return "F3" ; +case AS7343_CHAN_IDX_F4 : +return "F4" ; +case AS7343_CHAN_IDX_F6 : +return "F6" ; +case AS7343_CHAN_IDX_F1 : +return "F1" ; +case AS7343_CHAN_IDX_F7 : +return "F7" ; +case AS7343_CHAN_IDX_F8 : +return "F8" ; +case AS7343_CHAN_IDX_F5 : +return "F5" ; +default : +return NULL ; + }
drivers/iio/light/as7343.c line 197
Quoted 10 lines
drivers/iio/light/as7343.c new file +10
-0+} + +static int as7343_read_label (struct iio_dev *indio_dev, +struct iio_chan_spec const *chan,char *label) +{ +const char *name; + + name =as7343_channel_label (chan); +if (!name) +return -EINVAL ;
A blank line here would be better.
Quoted 12 lines
drivers/iio/light/as7343.c new file +12
-0+return sysfs_emit (label,"%s\n" , name); +} + +static const struct iio_info as7343_info = { + .read_raw = as7343_read_raw, + .read_label = as7343_read_label, +}; + +static const struct regmap_config as7343_regmap_config = { + .name ="as7343" , + .reg_bits =8 , + .val_bits =8 ,
drivers/iio/light/as7343.c line 219
Quoted 10 lines
drivers/iio/light/as7343.c new file +10
-0+ .max_register = AS7343_MAX, + .reg_format_endian = REGMAP_ENDIAN_LITTLE, + .val_format_endian = REGMAP_ENDIAN_LITTLE, + .cache_type = REGCACHE_NONE, +}; + +static int as7343_setup_device (struct device *dev,struct as7343_data *data) +{ +unsigned int val; +u16 step;
__le16 instead of u16.
drivers/iio/light/as7343.c line 232
Quoted 13 lines
drivers/iio/light/as7343.c new file +13
-0+int ret; + +/* Power on */ + ret =regmap_set_bits (data->regmap,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 (data->regmap,AS7343_CFG0 ,AS7343_CFG0_REG_BANK ); +if (ret) +return ret; + + ret =regmap_read (data->regmap,AS7343_ID , &val);
You should check the value of ret as well in case of a regmap failure.
Signature · 2 lines
Kind regards, Joshua Crofts