Introduce common generic led consumer binding, where consumer defines
led(s) by phandle, as opposed to trigger-source binding where the
trigger source is defined in led itself.
Add already used in some schemas 'leds' parameter which expects
phandle-array. Additionally, introduce 'led-names' which could be used
by consumers to map LED devices to their respective functions.
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
.../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/leds-consumer.yaml b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..d50a3850f6336e9e3a52eb1374e36ea50de27f47
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common leds consumer
+
+maintainers:
+ - Aleksandrs Vinarskis <alex@vinarskis.com>
+
+description:
+ Some LED defined in DT are required by other DT consumers, for example
+ v4l2 subnode may require privacy or flash LED. Unlike trigger-source
+ approach which is typically used as 'soft' binding, referencing LED
+ devices by phandle makes things simpler when 'hard' binding is desired.
+
+ Document LED properties that its consumers may define.
+
+select: true
+
+properties:
+ leds:
+ oneOf:
+ - type: object
+ - $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ A list of LED device(s) required by a particular consumer.
+ items:
+ maxItems: 1
+
+ led-names:
+ description:
+ A list of device name(s). Used to map LED devices to their respective
+ functions, when consumer requires more than one LED.
+
+additionalProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ leds {
+ compatible = "gpio-leds";
+
+ privacy_led: privacy-led {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_INDICATOR;
+ gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@36 {
+ compatible = "ovti,ov02c10";
+ reg = <0x36>;
+
+ reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_rgb_default>;
+
+ leds = <&privacy_led>;
+ led-names = "privacy-led";
+
+ clocks = <&ov02e10_clk>;
+
+ assigned-clocks = <&ov02e10_clk>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vreg_l7b_2p8>;
+ dvdd-supply = <&vreg_l7b_2p8>;
+ dovdd-supply = <&vreg_cam_1p8>;
+
+ port {
+ ov02e10_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <400000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+ };
+
+...
--
2.48.1
On Monday, September 8th, 2025 at 01:18, Aleksandrs Vinarskis <alex@vinarskis.com> wrote:
>
>
> Introduce common generic led consumer binding, where consumer defines
> led(s) by phandle, as opposed to trigger-source binding where the
> trigger source is defined in led itself.
>
> Add already used in some schemas 'leds' parameter which expects
> phandle-array. Additionally, introduce 'led-names' which could be used
> by consumers to map LED devices to their respective functions.
>
> Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com
>
> ---
> .../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-consumer.yaml b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..d50a3850f6336e9e3a52eb1374e36ea50de27f47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
> @@ -0,0 +1,89 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-consumer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common leds consumer
> +
> +maintainers:
> + - Aleksandrs Vinarskis alex@vinarskis.com
>
> +
> +description:
> + Some LED defined in DT are required by other DT consumers, for example
> + v4l2 subnode may require privacy or flash LED. Unlike trigger-source
> + approach which is typically used as 'soft' binding, referencing LED
> + devices by phandle makes things simpler when 'hard' binding is desired.
> +
> + Document LED properties that its consumers may define.
> +
> +select: true
> +
> +properties:
> + leds:
> + oneOf:
> + - type: object
> + - $ref: /schemas/types.yaml#/definitions/phandle-array
> + description:
> + A list of LED device(s) required by a particular consumer.
> + items:
> + maxItems: 1
> +
> + led-names:
While going over the feedback I realized `leds` and `led-names` do
not follow `property`, `property-names` convention. Any objections
if I rename `led-names` to `leds-names` for consistency?
Thanks,
Alex
> + description:
> + A list of device name(s). Used to map LED devices to their respective
> + functions, when consumer requires more than one LED.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
>
> + #include <dt-bindings/leds/common.h>
>
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + privacy_led: privacy-led {
> + color = <LED_COLOR_ID_RED>;
>
> + default-state = "off";
> + function = LED_FUNCTION_INDICATOR;
> + gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
>
> + };
> + };
> +
> + i2c {
> + #address-cells = <1>;
>
> + #size-cells = <0>;
>
> +
> + camera@36 {
> + compatible = "ovti,ov02c10";
> + reg = <0x36>;
>
> +
> + reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
>
> + pinctrl-names = "default";
> + pinctrl-0 = <&cam_rgb_default>;
>
> +
> + leds = <&privacy_led>;
>
> + led-names = "privacy-led";
> +
> + clocks = <&ov02e10_clk>;
>
> +
> + assigned-clocks = <&ov02e10_clk>;
>
> + assigned-clock-rates = <19200000>;
>
> +
> + avdd-supply = <&vreg_l7b_2p8>;
>
> + dvdd-supply = <&vreg_l7b_2p8>;
>
> + dovdd-supply = <&vreg_cam_1p8>;
>
> +
> + port {
> + ov02e10_ep: endpoint {
> + data-lanes = <1 2>;
>
> + link-frequencies = /bits/ 64 <400000000>;
>
> + remote-endpoint = <&csiphy4_ep>;
>
> + };
> + };
> + };
> + };
> +
> +...
>
> --
> 2.48.1
Hi, On 9-Sep-25 6:57 PM, Aleksandrs Vinarskis wrote: > > > > > > On Monday, September 8th, 2025 at 01:18, Aleksandrs Vinarskis <alex@vinarskis.com> wrote: > >> >> >> Introduce common generic led consumer binding, where consumer defines >> led(s) by phandle, as opposed to trigger-source binding where the >> trigger source is defined in led itself. >> >> Add already used in some schemas 'leds' parameter which expects >> phandle-array. Additionally, introduce 'led-names' which could be used >> by consumers to map LED devices to their respective functions. >> >> Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com >> >> --- >> .../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++ >> 1 file changed, 89 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/leds/leds-consumer.yaml b/Documentation/devicetree/bindings/leds/leds-consumer.yaml >> new file mode 100644 >> index 0000000000000000000000000000000000000000..d50a3850f6336e9e3a52eb1374e36ea50de27f47 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml >> @@ -0,0 +1,89 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/leds/leds-consumer.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Common leds consumer >> + >> +maintainers: >> + - Aleksandrs Vinarskis alex@vinarskis.com >> >> + >> +description: >> + Some LED defined in DT are required by other DT consumers, for example >> + v4l2 subnode may require privacy or flash LED. Unlike trigger-source >> + approach which is typically used as 'soft' binding, referencing LED >> + devices by phandle makes things simpler when 'hard' binding is desired. >> + >> + Document LED properties that its consumers may define. >> + >> +select: true >> + >> +properties: >> + leds: >> + oneOf: >> + - type: object >> + - $ref: /schemas/types.yaml#/definitions/phandle-array >> + description: >> + A list of LED device(s) required by a particular consumer. >> + items: >> + maxItems: 1 >> + >> + led-names: > > While going over the feedback I realized `leds` and `led-names` do > not follow `property`, `property-names` convention. Any objections > if I rename `led-names` to `leds-names` for consistency? No objections from me, `leds-names` indeed is better. Regards, Hans
On Mon, 08 Sep 2025 01:18:03 +0200, Aleksandrs Vinarskis wrote:
> Introduce common generic led consumer binding, where consumer defines
> led(s) by phandle, as opposed to trigger-source binding where the
> trigger source is defined in led itself.
>
> Add already used in some schemas 'leds' parameter which expects
> phandle-array. Additionally, introduce 'led-names' which could be used
> by consumers to map LED devices to their respective functions.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
> .../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/leds-consumer.example.dtb: camera@36 (ovti,ov02c10): Unevaluated properties are not allowed ('led-names', 'leds' were unexpected)
from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov02e10.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250908-leds-v3-1-5944dc400668@vinarskis.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
On Monday, September 8th, 2025 at 16:15, Rob Herring (Arm) <robh@kernel.org> wrote:
>
>
>
> On Mon, 08 Sep 2025 01:18:03 +0200, Aleksandrs Vinarskis wrote:
>
> > Introduce common generic led consumer binding, where consumer defines
> > led(s) by phandle, as opposed to trigger-source binding where the
> > trigger source is defined in led itself.
> >
> > Add already used in some schemas 'leds' parameter which expects
> > phandle-array. Additionally, introduce 'led-names' which could be used
> > by consumers to map LED devices to their respective functions.
> >
> > Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com
> > ---
> > .../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++
> > 1 file changed, 89 insertions(+)
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/leds-consumer.example.dtb: camera@36 (ovti,ov02c10): Unevaluated properties are not allowed ('led-names', 'leds' were unexpected)
> from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov02e10.yaml#
Rob: this is because the 1st patch that adds `led-consumer.yaml` uses
ov02e10 in its example, while the property is added to
`video-interface-devices.yaml` (which is used by ov02e10 and other
cameras) only in the 2nd patch. As I see it, reversing the order of 1st
and 2nd patch would likewise cause 'error' when 1st patch is checked
without the 2nd one. I don't think that 1st and 2nd patches should be
combined, but if you prefer to do that so the warning goes away - please
let me know.
When running checks on the entire series/last commit, no binding errors
are present.
Alex
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250908-leds-v3-1-5944dc400668@vinarskis.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in this patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
On Mon, Sep 08, 2025 at 03:43:22PM +0000, Aleksandrs Vinarskis wrote:
>
>
>
>
>
> On Monday, September 8th, 2025 at 16:15, Rob Herring (Arm) <robh@kernel.org> wrote:
>
> >
> >
> >
> > On Mon, 08 Sep 2025 01:18:03 +0200, Aleksandrs Vinarskis wrote:
> >
> > > Introduce common generic led consumer binding, where consumer defines
> > > led(s) by phandle, as opposed to trigger-source binding where the
> > > trigger source is defined in led itself.
> > >
> > > Add already used in some schemas 'leds' parameter which expects
> > > phandle-array. Additionally, introduce 'led-names' which could be used
> > > by consumers to map LED devices to their respective functions.
> > >
> > > Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com
> > > ---
> > > .../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++
> > > 1 file changed, 89 insertions(+)
> >
> >
> > My bot found errors running 'make dt_binding_check' on your patch:
> >
> > yamllint warnings/errors:
> >
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/leds-consumer.example.dtb: camera@36 (ovti,ov02c10): Unevaluated properties are not allowed ('led-names', 'leds' were unexpected)
> > from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov02e10.yaml#
>
> Rob: this is because the 1st patch that adds `led-consumer.yaml` uses
> ov02e10 in its example, while the property is added to
> `video-interface-devices.yaml` (which is used by ov02e10 and other
> cameras) only in the 2nd patch. As I see it, reversing the order of 1st
> and 2nd patch would likewise cause 'error' when 1st patch is checked
> without the 2nd one. I don't think that 1st and 2nd patches should be
> combined, but if you prefer to do that so the warning goes away - please
> let me know.
>
Just drop the compatible (and most of the properties) from the example.
That's a common binding, so adding there some other device DTS only
complicates things. See access-controllers, for example.
Best regards,
Krzysztof
© 2016 - 2025 Red Hat, Inc.