Re: [PATCH v3 1/4] dt-bindings: leds: add generic LED consumer documentation
From: Aleksandrs Vinarskis <hidden>
Date: 2025-09-09 16:58:10
Also in:
dri-devel, linux-arm-msm, linux-leds, linux-media, lkml
On Monday, September 8th, 2025 at 01:18, Aleksandrs Vinarskis [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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