On Monday, September 8th, 2025 at 01:18, Aleksandrs Vinarskis
<a...@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 a...@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 a...@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
