[PATCH v2 0/4] leds: privacy-led support for devicetree

[PATCH v2 0/4] leds: privacy-led support for devicetree

[Aleksandrs Vinarskis]

Re-spin of RFC patch from ~2.5 years ago [1]. v4l2 controls for privacy
LEDs has landed, but the DT part was left out. Introduce missing
dt-bindings, and commonize 'leds' parameter. Finally, add a patch to
enable privacy-led on Lenovo Thinkpad x13s.

With recent inflow of arm64-power laptops (Snapdragon X1E/X1P) which
mostly use MIPI cameras, this feature becomes more desired. Original
rebased patch is still working as expected (with respective DT changes)
on Dell XPS 9345.

Changelog to original series:
- Pick RFC patch, pick R-by, drop RFC-related commit message part
- Add new DT binding to describe generic LED consumer properties
- Rebase and test on X1E laptop

[1] https://lore.kernel.org/all/20230120114524.408368-6-hdegoede@redhat.com/

Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
Changes in v2:
- Fixed mailing issue
- Fixed wrong R-by, add my missing sign-off
- Elaborated cover letter/commits descriptions to better describe why
  this is needed, and why trigger-source could not be used instead
- dt-bindings: expanded schema description, fixed s/phandle/phandle-array/,
  expanded the example
- dt-bindings: added patch to commonize 'leds' from other schemas
- leds: dropped wrapper, dropped exporting of private functions
- dts: added patch to utilize privacy-led on Lenovo Thinkpad x13s
- Link to v1: https://lore.kernel.org/all/010201990a1f5ad8-fc97fc84-9ef9-4a03-bf1c-2d54423c6497-000000@eu-west-1.amazonses.com/

---
Aleksandrs Vinarskis (3):
      dt-bindings: leds: add generic LED consumer documentation
      dt-bindings: leds: commonize leds property
      arm64: dts: qcom: sc8280xp-x13s: enable camera privacy indicator

Hans de Goede (1):
      leds: led-class: Add devicetree support to led_get()

 .../bindings/leds/backlight/led-backlight.yaml     |  7 +-
 .../devicetree/bindings/leds/leds-consumer.yaml    | 85 ++++++++++++++++++++++
 .../bindings/leds/leds-group-multicolor.yaml       |  6 +-
 .../bindings/media/video-interface-devices.yaml    |  3 +
 .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts     |  9 +--
 drivers/leds/led-class.c                           | 19 ++++-
 6 files changed, 111 insertions(+), 18 deletions(-)
---
base-commit: 3db46a82d467bd23d9ebc473d872a865785299d8
change-id: 20250902-leds-c61c877add80

Best regards,
-- 
Aleksandrs Vinarskis <alex@vinarskis.com>

[PATCH v2 1/4] dt-bindings: leds: add generic LED consumer documentation

[Aleksandrs Vinarskis]

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    | 85 ++++++++++++++++++++++
 1 file changed, 85 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..077dbe3ad9ff3fa15236b8dd1f448c00271e4810
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
@@ -0,0 +1,85 @@
+# 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.
+
+properties:
+  leds:
+    $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>;
+
+        led-names = "privacy-led";
+        leds = <&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

Re: [PATCH v2 1/4] dt-bindings: leds: add generic LED consumer documentation

[Konrad Dybcio]

On 9/5/25 9:59 AM, 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>
> ---

[...]

> +    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>;
> +
> +        led-names = "privacy-led";
> +        leds = <&privacy_led>;

property
property-names

is a common pattern

I know this is just an example, but people will copypaste it

Konrad

Re: [PATCH v2 1/4] dt-bindings: leds: add generic LED consumer documentation

[Rob Herring (Arm)]

On Fri, 05 Sep 2025 09:59:29 +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    | 85 ++++++++++++++++++++++
>  1 file changed, 85 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/20250905-leds-v2-1-ed8f66f56da8@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.

Re: [PATCH v2 1/4] dt-bindings: leds: add generic LED consumer documentation

[Rob Herring]

On Fri, Sep 05, 2025 at 09:59:29AM +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.

Please update the existing user dropping the type $ref and indicate how 
many entries (i.e. "maxItems: 1").

> 
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
>  .../devicetree/bindings/leds/leds-consumer.yaml    | 85 ++++++++++++++++++++++
>  1 file changed, 85 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..077dbe3ad9ff3fa15236b8dd1f448c00271e4810
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
> @@ -0,0 +1,85 @@
> +# 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:
> +    $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>;
> +
> +        led-names = "privacy-led";
> +        leds = <&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
> 

Re: [PATCH v2 1/4] dt-bindings: leds: add generic LED consumer documentation

[Rob Herring]

On Fri, Sep 05, 2025 at 10:17:39AM -0500, Rob Herring wrote:
> On Fri, Sep 05, 2025 at 09:59:29AM +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.
> 
> Please update the existing user dropping the type $ref and indicate how 
> many entries (i.e. "maxItems: 1").

Nevermind, I see you did...

> 
> > 
> > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > ---
> >  .../devicetree/bindings/leds/leds-consumer.yaml    | 85 ++++++++++++++++++++++
> >  1 file changed, 85 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..077dbe3ad9ff3fa15236b8dd1f448c00271e4810
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
> > @@ -0,0 +1,85 @@
> > +# 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:
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +    description:
> > +      A list of LED device(s) required by a particular consumer.
> > +    items:
> > +      maxItems: 1

Also, the select is going to cause a problem with nodes named 'leds', so 
it will need to be:

leds:
  oneOf:
    - type: object
    - $ref: /schemas/types.yaml#/definitions/phandle-array
      ...

> > +
> > +  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>;
> > +
> > +        led-names = "privacy-led";
> > +        leds = <&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
> > 

[PATCH v2 2/4] dt-bindings: leds: commonize leds property

[Aleksandrs Vinarskis]

A number of existing schemas use 'leds' property to provide
phandle-array of LED(s) to the consumer. Additionally, with the
upcoming privacy-led support in device-tree, v4l2 subnode could be a
LED consumer, meaning that all camera sensors should support 'leds'
and 'led-names' property via common 'video-interface-devices.yaml'.

To avoid dublication, commonize 'leds' property from existing schemas
to newly introduced 'led-consumer.yaml'.

Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
 .../devicetree/bindings/leds/backlight/led-backlight.yaml          | 7 +------
 Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml  | 6 +-----
 .../devicetree/bindings/media/video-interface-devices.yaml         | 3 +++
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
index f5554da6bc6c73e94c4a2c32b150b28351b25f16..5e19b4376715eeb05cb789255db209ed27f8822f 100644
--- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
@@ -18,17 +18,12 @@ description:
 
 allOf:
   - $ref: common.yaml#
+  - $ref: /schemas/leds/leds-consumer.yaml#
 
 properties:
   compatible:
     const: led-backlight
 
-  leds:
-    description: A list of LED nodes
-    $ref: /schemas/types.yaml#/definitions/phandle-array
-    items:
-      maxItems: 1
-
 required:
   - compatible
   - leds
diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
index 8ed059a5a724f68389a1d0c4396c85b9ccb2d9af..b4f326e8822a3bf452b22f5b9fa7189696f760a4 100644
--- a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
@@ -17,16 +17,12 @@ properties:
   compatible:
     const: leds-group-multicolor
 
-  leds:
-    description:
-      An aray of monochromatic leds
-    $ref: /schemas/types.yaml#/definitions/phandle-array
-
 required:
   - leds
 
 allOf:
   - $ref: leds-class-multicolor.yaml#
+  - $ref: /schemas/leds/leds-consumer.yaml#
 
 unevaluatedProperties: false
 
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
index cf7712ad297c01c946fa4dfdaf9a21646e125099..1e25cea0ff71da2cfd1c7c4642713199f3542c0a 100644
--- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -10,6 +10,9 @@ maintainers:
   - Jacopo Mondi <jacopo@jmondi.org>
   - Sakari Ailus <sakari.ailus@linux.intel.com>
 
+allOf:
+  - $ref: /schemas/leds/leds-consumer.yaml#
+
 properties:
   flash-leds:
     $ref: /schemas/types.yaml#/definitions/phandle-array

-- 
2.48.1

Re: [PATCH v2 2/4] dt-bindings: leds: commonize leds property

[Rob Herring]

On Fri, Sep 05, 2025 at 09:59:30AM +0200, Aleksandrs Vinarskis wrote:
> A number of existing schemas use 'leds' property to provide
> phandle-array of LED(s) to the consumer. Additionally, with the
> upcoming privacy-led support in device-tree, v4l2 subnode could be a
> LED consumer, meaning that all camera sensors should support 'leds'
> and 'led-names' property via common 'video-interface-devices.yaml'.
> 
> To avoid dublication, commonize 'leds' property from existing schemas
> to newly introduced 'led-consumer.yaml'.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
>  .../devicetree/bindings/leds/backlight/led-backlight.yaml          | 7 +------
>  Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml  | 6 +-----
>  .../devicetree/bindings/media/video-interface-devices.yaml         | 3 +++
>  3 files changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> index f5554da6bc6c73e94c4a2c32b150b28351b25f16..5e19b4376715eeb05cb789255db209ed27f8822f 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> @@ -18,17 +18,12 @@ description:
>  
>  allOf:
>    - $ref: common.yaml#
> +  - $ref: /schemas/leds/leds-consumer.yaml#

Drop.

>  
>  properties:
>    compatible:
>      const: led-backlight
>  
> -  leds:
> -    description: A list of LED nodes
> -    $ref: /schemas/types.yaml#/definitions/phandle-array
> -    items:
> -      maxItems: 1

You need to keep the property here:

leds: true

> -
>  required:
>    - compatible
>    - leds
> diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> index 8ed059a5a724f68389a1d0c4396c85b9ccb2d9af..b4f326e8822a3bf452b22f5b9fa7189696f760a4 100644
> --- a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> +++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> @@ -17,16 +17,12 @@ properties:
>    compatible:
>      const: leds-group-multicolor
>  
> -  leds:
> -    description:
> -      An aray of monochromatic leds
> -    $ref: /schemas/types.yaml#/definitions/phandle-array
> -
>  required:
>    - leds
>  
>  allOf:
>    - $ref: leds-class-multicolor.yaml#
> +  - $ref: /schemas/leds/leds-consumer.yaml#


Same comments in this one.

>  
>  unevaluatedProperties: false
>  
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> index cf7712ad297c01c946fa4dfdaf9a21646e125099..1e25cea0ff71da2cfd1c7c4642713199f3542c0a 100644
> --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -10,6 +10,9 @@ maintainers:
>    - Jacopo Mondi <jacopo@jmondi.org>
>    - Sakari Ailus <sakari.ailus@linux.intel.com>
>  
> +allOf:
> +  - $ref: /schemas/leds/leds-consumer.yaml#

This can be dropped. The user still has to define how many entries and 
what the values of led-names are.

> +
>  properties:
>    flash-leds:
>      $ref: /schemas/types.yaml#/definitions/phandle-array
> 
> -- 
> 2.48.1
> 

Re: [PATCH v2 2/4] dt-bindings: leds: commonize leds property

[Aleksandrs Vinarskis]

On Friday, September 5th, 2025 at 17:24, Rob Herring <robh@kernel.org> wrote:

> 
> 
> On Fri, Sep 05, 2025 at 09:59:30AM +0200, Aleksandrs Vinarskis wrote:
> 
> > A number of existing schemas use 'leds' property to provide
> > phandle-array of LED(s) to the consumer. Additionally, with the
> > upcoming privacy-led support in device-tree, v4l2 subnode could be a
> > LED consumer, meaning that all camera sensors should support 'leds'
> > and 'led-names' property via common 'video-interface-devices.yaml'.
> > 
> > To avoid dublication, commonize 'leds' property from existing schemas
> > to newly introduced 'led-consumer.yaml'.
> > 
> > Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com
> > ---
> > .../devicetree/bindings/leds/backlight/led-backlight.yaml | 7 +------
> > Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml | 6 +-----
> > .../devicetree/bindings/media/video-interface-devices.yaml | 3 +++
> > 3 files changed, 5 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > index f5554da6bc6c73e94c4a2c32b150b28351b25f16..5e19b4376715eeb05cb789255db209ed27f8822f 100644
> > --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > @@ -18,17 +18,12 @@ description:
> > 
> > allOf:
> > - $ref: common.yaml#
> > + - $ref: /schemas/leds/leds-consumer.yaml#
> 
> 
> Drop.
> 
> > properties:
> > compatible:
> > const: led-backlight
> > 
> > - leds:
> > - description: A list of LED nodes
> > - $ref: /schemas/types.yaml#/definitions/phandle-array
> > - items:
> > - maxItems: 1
> 
> 
> You need to keep the property here:
> 
> leds: true
> 
> > -
> > required:
> > - compatible
> > - leds
> > diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> > index 8ed059a5a724f68389a1d0c4396c85b9ccb2d9af..b4f326e8822a3bf452b22f5b9fa7189696f760a4 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> > +++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> > @@ -17,16 +17,12 @@ properties:
> > compatible:
> > const: leds-group-multicolor
> > 
> > - leds:
> > - description:
> > - An aray of monochromatic leds
> > - $ref: /schemas/types.yaml#/definitions/phandle-array
> > -
> > required:
> > - leds
> > 
> > allOf:
> > - $ref: leds-class-multicolor.yaml#
> > + - $ref: /schemas/leds/leds-consumer.yaml#
> 
> 
> 
> Same comments in this one.
> 
> > unevaluatedProperties: false
> > 
> > diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> > index cf7712ad297c01c946fa4dfdaf9a21646e125099..1e25cea0ff71da2cfd1c7c4642713199f3542c0a 100644
> > --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> > +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> > @@ -10,6 +10,9 @@ maintainers:
> > - Jacopo Mondi jacopo@jmondi.org
> > - Sakari Ailus sakari.ailus@linux.intel.com
> > 
> > +allOf:
> > + - $ref: /schemas/leds/leds-consumer.yaml#
> 
> 
> This can be dropped. The user still has to define how many entries and
> what the values of led-names are.

Hmm, but where should it be added then? If I just drop it, MIPI camera schemas which are based on 'video-interface-devices.yaml' and have 'unevaluatedProperties: false' throw warnings because 'leds' was not expected. Including the example in 'led-consumer.yaml' as found by your bot (because of patch order your bot only run on 1/4, adding this very change fixes it).
In this case, v4l2 subnode is the LED user, which is some camera. It seems most/all of these cameras are based on this binding, so instead of adding new led related properties to all of them, I thought this is a good common place for it... Shall I add #entries and available options for 'led-names' here to make it complete?

Thanks,
Alex

> 
> > +
> > properties:
> > flash-leds:
> > $ref: /schemas/types.yaml#/definitions/phandle-array
> > 
> > --
> > 2.48.1

Re: [PATCH v2 2/4] dt-bindings: leds: commonize leds property

[Rob Herring]

On Fri, Sep 05, 2025 at 04:48:52PM +0000, Aleksandrs Vinarskis wrote:
> On Friday, September 5th, 2025 at 17:24, Rob Herring <robh@kernel.org> wrote:
> 
> > 
> > 
> > On Fri, Sep 05, 2025 at 09:59:30AM +0200, Aleksandrs Vinarskis wrote:
> > 
> > > A number of existing schemas use 'leds' property to provide
> > > phandle-array of LED(s) to the consumer. Additionally, with the
> > > upcoming privacy-led support in device-tree, v4l2 subnode could be a
> > > LED consumer, meaning that all camera sensors should support 'leds'
> > > and 'led-names' property via common 'video-interface-devices.yaml'.
> > > 
> > > To avoid dublication, commonize 'leds' property from existing schemas
> > > to newly introduced 'led-consumer.yaml'.
> > > 
> > > Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com
> > > ---
> > > .../devicetree/bindings/leds/backlight/led-backlight.yaml | 7 +------
> > > Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml | 6 +-----
> > > .../devicetree/bindings/media/video-interface-devices.yaml | 3 +++
> > > 3 files changed, 5 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > > index f5554da6bc6c73e94c4a2c32b150b28351b25f16..5e19b4376715eeb05cb789255db209ed27f8822f 100644
> > > --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > > @@ -18,17 +18,12 @@ description:
> > > 
> > > allOf:
> > > - $ref: common.yaml#
> > > + - $ref: /schemas/leds/leds-consumer.yaml#
> > 
> > 
> > Drop.
> > 
> > > properties:
> > > compatible:
> > > const: led-backlight
> > > 
> > > - leds:
> > > - description: A list of LED nodes
> > > - $ref: /schemas/types.yaml#/definitions/phandle-array
> > > - items:
> > > - maxItems: 1
> > 
> > 
> > You need to keep the property here:
> > 
> > leds: true
> > 
> > > -
> > > required:
> > > - compatible
> > > - leds
> > > diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> > > index 8ed059a5a724f68389a1d0c4396c85b9ccb2d9af..b4f326e8822a3bf452b22f5b9fa7189696f760a4 100644
> > > --- a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> > > +++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
> > > @@ -17,16 +17,12 @@ properties:
> > > compatible:
> > > const: leds-group-multicolor
> > > 
> > > - leds:
> > > - description:
> > > - An aray of monochromatic leds
> > > - $ref: /schemas/types.yaml#/definitions/phandle-array
> > > -
> > > required:
> > > - leds
> > > 
> > > allOf:
> > > - $ref: leds-class-multicolor.yaml#
> > > + - $ref: /schemas/leds/leds-consumer.yaml#
> > 
> > 
> > 
> > Same comments in this one.
> > 
> > > unevaluatedProperties: false
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> > > index cf7712ad297c01c946fa4dfdaf9a21646e125099..1e25cea0ff71da2cfd1c7c4642713199f3542c0a 100644
> > > --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> > > +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> > > @@ -10,6 +10,9 @@ maintainers:
> > > - Jacopo Mondi jacopo@jmondi.org
> > > - Sakari Ailus sakari.ailus@linux.intel.com
> > > 
> > > +allOf:
> > > + - $ref: /schemas/leds/leds-consumer.yaml#
> > 
> > 
> > This can be dropped. The user still has to define how many entries and
> > what the values of led-names are.
> 
> Hmm, but where should it be added then? If I just drop it, MIPI 
> camera schemas which are based on 'video-interface-devices.yaml' and 
> have 'unevaluatedProperties: false' throw warnings because 'leds' was 
> not expected. Including the example in 'led-consumer.yaml' as found 
> by your bot (because of patch order your bot only run on 1/4, adding 
> this very change fixes it).

> In this case, v4l2 subnode is the LED user, which is some camera. It 
> seems most/all of these cameras are based on this binding, so instead 
> of adding new led related properties to all of them, I thought this 
> is a good common place for it... Shall I add #entries and available 
> options for 'led-names' here to make it complete?

Every camera doesn't have the same LEDs, so you have to define exactly 
what's there for each one. If you want to do it in 
video-interface-devices.yanl, then you are standardizing it for 
everyone. Maybe that's fine? If so, you need something like:

leds:
  minItems: 1
  maxItems: 2

led-names:
  items:
    enum:
      - flash
      - privacy

Rob

[PATCH v2 3/4] leds: led-class: Add devicetree support to led_get()

[Aleksandrs Vinarskis]

From: Hans de Goede <hansg@kernel.org>

Add 'name' argument to of_led_get() such that it can lookup LEDs in
devicetree by either name or index.

And use this modified function to add devicetree support to the generic
(non devicetree specific) [devm_]led_get() function.

This uses the standard devicetree pattern of adding a -names string array
to map names to the indexes for an array of resources.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
 drivers/leds/led-class.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 15633fbf3c166aa4f521774d245f6399a642bced..982eb4c1aac998e85b104d7cba26e786ca62056f 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -252,15 +252,23 @@ static const struct class leds_class = {
  * of_led_get() - request a LED device via the LED framework
  * @np: device node to get the LED device from
  * @index: the index of the LED
+ * @name: the name of the LED used to map it to its function, if present
  *
  * Returns the LED device parsed from the phandle specified in the "leds"
  * property of a device tree node or a negative error-code on failure.
  */
-static struct led_classdev *of_led_get(struct device_node *np, int index)
+static struct led_classdev *of_led_get(struct device_node *np, int index,
+				       const char *name)
 {
 	struct device *led_dev;
 	struct device_node *led_node;
 
+	/*
+	 * For named LEDs, first look up the name in the "led-names" property.
+	 * If it cannot be found, then of_parse_phandle() will propagate the error.
+	 */
+	if (name)
+		index = of_property_match_string(np, "led-names", name);
 	led_node = of_parse_phandle(np, "leds", index);
 	if (!led_node)
 		return ERR_PTR(-ENOENT);
@@ -324,7 +332,7 @@ struct led_classdev *__must_check devm_of_led_get(struct device *dev,
 	if (!dev)
 		return ERR_PTR(-EINVAL);
 
-	led = of_led_get(dev->of_node, index);
+	led = of_led_get(dev->of_node, index, NULL);
 	if (IS_ERR(led))
 		return led;
 
@@ -342,9 +350,16 @@ EXPORT_SYMBOL_GPL(devm_of_led_get);
 struct led_classdev *led_get(struct device *dev, char *con_id)
 {
 	struct led_lookup_data *lookup;
+	struct led_classdev *led_cdev;
 	const char *provider = NULL;
 	struct device *led_dev;
 
+	if (dev->of_node) {
+		led_cdev = of_led_get(dev->of_node, -1, con_id);
+		if (!IS_ERR(led_cdev) || PTR_ERR(led_cdev) != -ENOENT)
+			return led_cdev;
+	}
+
 	mutex_lock(&leds_lookup_lock);
 	list_for_each_entry(lookup, &leds_lookup_list, list) {
 		if (!strcmp(lookup->dev_id, dev_name(dev)) &&

-- 
2.48.1

Re: [PATCH v2 3/4] leds: led-class: Add devicetree support to led_get()

[Andy Shevchenko]

On Fri, Sep 5, 2025 at 11:00 AM Aleksandrs Vinarskis <alex@vinarskis.com> wrote:

> Add 'name' argument to of_led_get() such that it can lookup LEDs in
> devicetree by either name or index.
>
> And use this modified function to add devicetree support to the generic
> (non devicetree specific) [devm_]led_get() function.
>
> This uses the standard devicetree pattern of adding a -names string array
> to map names to the indexes for an array of resources.

...

> +       if (dev->of_node) {

This check is not needed.

Currently of_led_get() returns -ENOENT if the np is NULL or index is
invalid (negative value).
Same will be with the added index search as in case of error it will
hold a negative value.

> +               led_cdev = of_led_get(dev->of_node, -1, con_id);
> +               if (!IS_ERR(led_cdev) || PTR_ERR(led_cdev) != -ENOENT)
> +                       return led_cdev;
> +       }

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 4/4] arm64: dts: qcom: sc8280xp-x13s: enable camera privacy indicator

[Aleksandrs Vinarskis]

Leverage newly introduced 'leds' and 'led-names' properties to pass
indicator's phandle and function to v4l2 subnode. The latter supports
privacy led since couple of years ago under 'privacy-led' designation.
Unlike initially proposed trigger-source based approach, this solution
cannot be easily bypassed from userspace, thus reducing privacy
concerns.

Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 637430719e6d7d3c0eeb4abf2b80eea1f8289530..03801b174713cb9962c10072a73e9516abc45930 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -83,15 +83,11 @@ leds {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cam_indicator_en>;
 
-		led-camera-indicator {
-			label = "white:camera-indicator";
+		privacy_led: privacy-led {
 			function = LED_FUNCTION_INDICATOR;
 			color = <LED_COLOR_ID_WHITE>;
 			gpios = <&tlmm 28 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "none";
 			default-state = "off";
-			/* Reuse as a panic indicator until we get a "camera on" trigger */
-			panic-indicator;
 		};
 	};
 
@@ -685,6 +681,9 @@ camera@10 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cam_rgb_default>;
 
+		led-names = "privacy-led";
+		leds = <&privacy_led>;
+
 		clocks = <&camcc CAMCC_MCLK3_CLK>;
 
 		orientation = <0>;	/* Front facing */

-- 
2.48.1

Re: [PATCH v2 4/4] arm64: dts: qcom: sc8280xp-x13s: enable camera privacy indicator

[Konrad Dybcio]

On 9/5/25 9:59 AM, Aleksandrs Vinarskis wrote:
> Leverage newly introduced 'leds' and 'led-names' properties to pass
> indicator's phandle and function to v4l2 subnode. The latter supports
> privacy led since couple of years ago under 'privacy-led' designation.
> Unlike initially proposed trigger-source based approach, this solution
> cannot be easily bypassed from userspace, thus reducing privacy
> concerns.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
>  arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index 637430719e6d7d3c0eeb4abf2b80eea1f8289530..03801b174713cb9962c10072a73e9516abc45930 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -83,15 +83,11 @@ leds {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&cam_indicator_en>;
>  
> -		led-camera-indicator {
> -			label = "white:camera-indicator";
> +		privacy_led: privacy-led {
>  			function = LED_FUNCTION_INDICATOR;
>  			color = <LED_COLOR_ID_WHITE>;
>  			gpios = <&tlmm 28 GPIO_ACTIVE_HIGH>;
> -			linux,default-trigger = "none";
>  			default-state = "off";
> -			/* Reuse as a panic indicator until we get a "camera on" trigger */
> -			panic-indicator;

I think panic-indicator may stay, as it's useful and mostly mutually
exclusive (bar some multi-OS use cases) with the camera being on,
with the comment above it obviously being removed as you did

Konrad