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

[PATCH v5 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 v5:
- Fix last occurance of `privacy-led` to `privacy`
- Link to v4: https://lore.kernel.org/r/20250910-leds-v4-0-1fc320488233@vinarskis.com

Changes in v4:
- Rename `privacy-led` to `privacy`, depend on x86/ACPI change
- Simplify example in dt-binding for led-consumer.yaml
- This series now depends on: https://lore.kernel.org/all/20250910104702.7470-1-hansg@kernel.org/
- Link to v3: https://lore.kernel.org/r/20250908-leds-v3-0-5944dc400668@vinarskis.com

Changes in v3:
- Drop unnecessary 'dev->of_node' check by Andy
- Keep 'panic-indicator;' in DT by Konrad
- Fix property/property-name order by Konrad
- Add missing 'led-names' enum definition for video devices by Rob
- Add oneOf to 'leds' to avoid conflict with nodes of same name by Rob
- Link to v2: https://lore.kernel.org/r/20250905-leds-v2-0-ed8f66f56da8@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     |  6 +-
 .../devicetree/bindings/leds/leds-consumer.yaml    | 67 ++++++++++++++++++++++
 .../bindings/leds/leds-group-multicolor.yaml       |  5 +-
 .../bindings/media/video-interface-devices.yaml    |  8 +++
 .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts     |  8 +--
 drivers/leds/led-class.c                           | 17 +++++-
 6 files changed, 96 insertions(+), 15 deletions(-)
---
base-commit: 3db46a82d467bd23d9ebc473d872a865785299d8
change-id: 20250902-leds-c61c877add80
prerequisite-message-id: <20250910104702.7470-1-hansg@kernel.org>
prerequisite-patch-id: 429eb224c966424b458a7179e10e1f3172408eb8

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

[PATCH v5 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    | 67 ++++++++++++++++++++++
 1 file changed, 67 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..fe6a0faa1d3b8ff55e05dfdc7697ed2246f0cede
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
@@ -0,0 +1,67 @@
+# 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>;
+
+      v4l2_node: camera@36 {
+        reg = <0x36>;
+
+        leds = <&privacy_led>;
+        led-names = "privacy";
+      };
+    };
+
+...

-- 
2.48.1

[PATCH v5 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         | 6 +-----
 Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml | 5 +----
 .../devicetree/bindings/media/video-interface-devices.yaml        | 8 ++++++++
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
index f5554da6bc6c73e94c4a2c32b150b28351b25f16..8fc5af8f27f9eb95b88eeeee32ad4774f5f21106 100644
--- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
@@ -23,11 +23,7 @@ properties:
   compatible:
     const: led-backlight
 
-  leds:
-    description: A list of LED nodes
-    $ref: /schemas/types.yaml#/definitions/phandle-array
-    items:
-      maxItems: 1
+  leds: true
 
 required:
   - compatible
diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
index 8ed059a5a724f68389a1d0c4396c85b9ccb2d9af..5c9cfa39396b0ba89830e520ade108bfd1a3f12e 100644
--- a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
@@ -17,10 +17,7 @@ properties:
   compatible:
     const: leds-group-multicolor
 
-  leds:
-    description:
-      An aray of monochromatic leds
-    $ref: /schemas/types.yaml#/definitions/phandle-array
+  leds: true
 
 required:
   - leds
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
index cf7712ad297c01c946fa4dfdaf9a21646e125099..3ad1590b04966f52c3643543f4ab28f71ab59638 100644
--- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -17,6 +17,14 @@ properties:
       An array of phandles, each referring to a flash LED, a sub-node of the LED
       driver device node.
 
+  leds:
+    minItems: 1
+    maxItems: 1
+
+  led-names:
+    enum:
+      - privacy
+
   lens-focus:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:

-- 
2.48.1

[PATCH v5 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 | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 15633fbf3c166aa4f521774d245f6399a642bced..f3faf37f9a08ac762ed87b91cb3cab5faa8eacb0 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,14 @@ 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;
 
+	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

[PATCH v5 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 | 8 ++++----
 1 file changed, 4 insertions(+), 4 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..3b3f7137689a6fa292ffe4fec8c1d1f20ee525bc 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -83,14 +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 +682,9 @@ camera@10 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cam_rgb_default>;
 
+		leds = <&privacy_led>;
+		led-names = "privacy";
+
 		clocks = <&camcc CAMCC_MCLK3_CLK>;
 
 		orientation = <0>;	/* Front facing */

-- 
2.48.1

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

[Konrad Dybcio]

On 9/10/25 2:01 PM, 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>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

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

[Konrad Dybcio]

On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote:
> 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>
> ---

I was thinking, perhaps we should introduce some sort of an exclusive
access mechanism, so that the e.g. user (or malware) can't listen to
uevents and immediately shut down the LED over sysfs

Konrad

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

[Aleksandrs Vinarskis]

On Wednesday, September 10th, 2025 at 14:22, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:

>
>
> On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote:
>
> > 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
> > ---
>
>
> I was thinking, perhaps we should introduce some sort of an exclusive
> access mechanism, so that the e.g. user (or malware) can't listen to
> uevents and immediately shut down the LED over sysfs

It is already done by the original series from Hans (linked in cover),
which was merged few years back. It is also the reason why this
approach is used instead of typically used trigger-source - that
would've indeed allowed anyone with access to sysfs to disable the
indicator.

As per Hans [1], v4l2-core would disable sysfs of privacy indicator:

    sd->privacy_led = led_get(sd->dev, "privacy-led")
    led_sysfs_disable(sd->privacy_led);


Of course, this security only holds if one has secure boot enforced,
kernel, modules, _and_ device-tree blobs are signed.

Regards,
Alex

[1] https://lore.kernel.org/all/daf442a6-b4d6-4213-8ec0-10397d682cc4@kernel.org/

>
> Konrad

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

[Konrad Dybcio]

On 9/10/25 2:54 PM, Aleksandrs Vinarskis wrote:
> 
> 
> 
> 
> 
> On Wednesday, September 10th, 2025 at 14:22, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> 
>>
>>
>> On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote:
>>
>>> 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
>>> ---
>>
>>
>> I was thinking, perhaps we should introduce some sort of an exclusive
>> access mechanism, so that the e.g. user (or malware) can't listen to
>> uevents and immediately shut down the LED over sysfs
> 
> It is already done by the original series from Hans (linked in cover),
> which was merged few years back. It is also the reason why this
> approach is used instead of typically used trigger-source - that
> would've indeed allowed anyone with access to sysfs to disable the
> indicator.
> 
> As per Hans [1], v4l2-core would disable sysfs of privacy indicator:
> 
>     sd->privacy_led = led_get(sd->dev, "privacy-led")
>     led_sysfs_disable(sd->privacy_led);
> 
> 
> Of course, this security only holds if one has secure boot enforced,
> kernel, modules, _and_ device-tree blobs are signed.

Great, thank you for this context

Konrad

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

[Steev Klimaszewski]

Hi Aleksandrs,

On Wed, Sep 10, 2025 at 7:01 AM Aleksandrs Vinarskis <alex@vinarskis.com> 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 | 8 ++++----
>  1 file changed, 4 insertions(+), 4 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..3b3f7137689a6fa292ffe4fec8c1d1f20ee525bc 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -83,14 +83,11 @@ leds {
>                 pinctrl-names = "default";
>                 pinctrl-0 = <&cam_indicator_en>;
>
> -               led-camera-indicator {
> -                       label = "white:camera-indicator";
> +               privacy_led: privacy-led {

Should this now be privacy_led: privacy { ?

>                         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 +682,9 @@ camera@10 {
>                 pinctrl-names = "default";
>                 pinctrl-0 = <&cam_rgb_default>;
>
> +               leds = <&privacy_led>;
> +               led-names = "privacy";
> +
>                 clocks = <&camcc CAMCC_MCLK3_CLK>;
>
>                 orientation = <0>;      /* Front facing */
>
> --
> 2.48.1
>

v5 does not turn the led on here on my X13s whereas v3 did (and v4 was
not tested)

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

[Steev Klimaszewski]

Hi Aleksandrs,

On Wed, Sep 10, 2025 at 12:04 PM Steev Klimaszewski <threeway@gmail.com> wrote:
>
> Hi Aleksandrs,
>
> On Wed, Sep 10, 2025 at 7:01 AM Aleksandrs Vinarskis <alex@vinarskis.com> 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 | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 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..3b3f7137689a6fa292ffe4fec8c1d1f20ee525bc 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > @@ -83,14 +83,11 @@ leds {
> >                 pinctrl-names = "default";
> >                 pinctrl-0 = <&cam_indicator_en>;
> >
> > -               led-camera-indicator {
> > -                       label = "white:camera-indicator";
> > +               privacy_led: privacy-led {
>
> Should this now be privacy_led: privacy { ?
>
> >                         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 +682,9 @@ camera@10 {
> >                 pinctrl-names = "default";
> >                 pinctrl-0 = <&cam_rgb_default>;
> >
> > +               leds = <&privacy_led>;
> > +               led-names = "privacy";
> > +
> >                 clocks = <&camcc CAMCC_MCLK3_CLK>;
> >
> >                 orientation = <0>;      /* Front facing */
> >
> > --
> > 2.48.1
> >
>
> v5 does not turn the led on here on my X13s whereas v3 did (and v4 was
> not tested)

From IRC conversations, the issue was not having
https://lore.kernel.org/all/20250910104702.7470-1-hansg@kernel.org
applied - with this prerequisite, v5 works here

Tested-by: Steev Klimaszewski <threeway@gmail.com>

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

[Lee Jones]

On Wed, 10 Sep 2025, Aleksandrs Vinarskis wrote:

> 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>

Remind me why this can't go in through LED again?

> 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 | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 15633fbf3c166aa4f521774d245f6399a642bced..f3faf37f9a08ac762ed87b91cb3cab5faa8eacb0 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,14 @@ 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;
>  
> +	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
> 
> 

-- 
Lee Jones [李琼斯]

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

[Hans de Goede]

Hi Lee,

On 11-Sep-25 10:15 AM, Lee Jones wrote:
> On Wed, 10 Sep 2025, Aleksandrs Vinarskis wrote:
> 
>> 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>
> 
> Remind me why this can't go in through LED again?

I don't think anyone has discussed how to merge this yet.

I believe that the LED tree is the correct tree to merge this
entire series through, once the DT bits have been reviewed.

Regards,

Hans




>> 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 | 17 +++++++++++++++--
>>  1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
>> index 15633fbf3c166aa4f521774d245f6399a642bced..f3faf37f9a08ac762ed87b91cb3cab5faa8eacb0 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,14 @@ 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;
>>  
>> +	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 v5 1/4] dt-bindings: leds: add generic LED consumer documentation

[Rob Herring (Arm)]

On Wed, 10 Sep 2025 14:01:08 +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    | 67 ++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

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

[Rob Herring (Arm)]

On Wed, 10 Sep 2025 14:01:09 +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         | 6 +-----
>  Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml | 5 +----
>  .../devicetree/bindings/media/video-interface-devices.yaml        | 8 ++++++++
>  3 files changed, 10 insertions(+), 9 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: (subset) [PATCH v5 0/4] leds: privacy-led support for devicetree

[Lee Jones]

On Wed, 10 Sep 2025 14:01:07 +0200, Aleksandrs Vinarskis wrote:
> 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.
> 
> [...]

Applied, thanks!

[1/4] dt-bindings: leds: add generic LED consumer documentation
      commit: 3f5df63955756fbe253a2a26043accf7318fa53a
[2/4] dt-bindings: leds: commonize leds property
      commit: 22420da3662a69d8894ee624494213a5888a1e87
[3/4] leds: led-class: Add devicetree support to led_get()
      commit: 7010cc08a6fd4ae4e68b05ec4f52c36cc0122f4c

--
Lee Jones [李琼斯]

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

[Bjorn Andersson]

On Thu, Sep 11, 2025 at 11:01:00AM +0200, Hans de Goede wrote:
> Hi Lee,
> 
> On 11-Sep-25 10:15 AM, Lee Jones wrote:
> > On Wed, 10 Sep 2025, Aleksandrs Vinarskis wrote:
> > 
> >> 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>
> > 
> > Remind me why this can't go in through LED again?
> 
> I don't think anyone has discussed how to merge this yet.
> 
> I believe that the LED tree is the correct tree to merge this
> entire series through, once the DT bits have been reviewed.
> 

Unless there are some strong reasons (that I'm failing to spot), we
should merge the DeviceTree binding and implementation through the LED
tree. Then I merge the DTS change through the Qualcomm DT tree once the
bindings are available in linux-next.

Regards,
Bjorn

> Regards,
> 
> Hans
> 
> 
> 
> 
> >> 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 | 17 +++++++++++++++--
> >>  1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> >> index 15633fbf3c166aa4f521774d245f6399a642bced..f3faf37f9a08ac762ed87b91cb3cab5faa8eacb0 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,14 @@ 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;
> >>  
> >> +	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 v5 3/4] leds: led-class: Add devicetree support to led_get()

[Lee Jones]

On Tue, 16 Sep 2025, Bjorn Andersson wrote:

> On Thu, Sep 11, 2025 at 11:01:00AM +0200, Hans de Goede wrote:
> > Hi Lee,
> > 
> > On 11-Sep-25 10:15 AM, Lee Jones wrote:
> > > On Wed, 10 Sep 2025, Aleksandrs Vinarskis wrote:
> > > 
> > >> 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>
> > > 
> > > Remind me why this can't go in through LED again?
> > 
> > I don't think anyone has discussed how to merge this yet.
> > 
> > I believe that the LED tree is the correct tree to merge this
> > entire series through, once the DT bits have been reviewed.
> > 
> 
> Unless there are some strong reasons (that I'm failing to spot), we
> should merge the DeviceTree binding and implementation through the LED
> tree. Then I merge the DTS change through the Qualcomm DT tree once the
> bindings are available in linux-next.

1-3 have been applied to the LED tree already.

-- 
Lee Jones [李琼斯]

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

[Aleksandrs Vinarskis]

On Tuesday, September 16th, 2025 at 18:07, Lee Jones <lee@kernel.org> wrote:

> 
> 
> On Tue, 16 Sep 2025, Bjorn Andersson wrote:
> 
> > On Thu, Sep 11, 2025 at 11:01:00AM +0200, Hans de Goede wrote:
> > 
> > > Hi Lee,
> > > 
> > > On 11-Sep-25 10:15 AM, Lee Jones wrote:
> > > 
> > > > On Wed, 10 Sep 2025, Aleksandrs Vinarskis wrote:
> > > > 
> > > > > 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
> > > > 
> > > > Remind me why this can't go in through LED again?
> > > 
> > > I don't think anyone has discussed how to merge this yet.
> > > 
> > > I believe that the LED tree is the correct tree to merge this
> > > entire series through, once the DT bits have been reviewed.
> > 
> > Unless there are some strong reasons (that I'm failing to spot), we
> > should merge the DeviceTree binding and implementation through the LED
> > tree. Then I merge the DTS change through the Qualcomm DT tree once the
> > bindings are available in linux-next.

Hi Bjorn,

The bindings are now in linux-next. Could you please pick the DTS change?

Thanks,
Alex

> 
> 
> 1-3 have been applied to the LED tree already.
> 
> --
> Lee Jones [李琼斯]

Re: (subset) [PATCH v5 0/4] leds: privacy-led support for devicetree

[Bjorn Andersson]

On Wed, 10 Sep 2025 14:01:07 +0200, Aleksandrs Vinarskis wrote:
> 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.
> 
> [...]

Applied, thanks!

[4/4] arm64: dts: qcom: sc8280xp-x13s: enable camera privacy indicator
      commit: b54c412b511c8bc8e71fd09a766bd95528d94840

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>