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

[PATCH v3 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 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    | 89 ++++++++++++++++++++++
 .../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, 118 insertions(+), 15 deletions(-)
---
base-commit: 3db46a82d467bd23d9ebc473d872a865785299d8
change-id: 20250902-leds-c61c877add80

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

[PATCH v3 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    | 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

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

[Rob Herring (Arm)]

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.

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

[Aleksandrs Vinarskis]

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.

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

[Krzysztof Kozlowski]

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

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

[Aleksandrs Vinarskis]

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

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

[Hans de Goede]

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

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

[Konrad Dybcio]

On 9/9/25 10:39 PM, Hans de Goede wrote:
> 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.

FWIW we have "clocks"/"clock-names", "resets"/"reset-names" etc.

I sometimes refer to "property"/"property-names" during review to
bring attention to the preferred style (ordering of such entries),
which is maybe what confused you

Konrad

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

[Aleksandrs Vinarskis]

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

> 
> 
> On 9/9/25 10:39 PM, Hans de Goede wrote:
> 
> > 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.
> 
> 
> FWIW we have "clocks"/"clock-names", "resets"/"reset-names" etc.
> 
> I sometimes refer to "property"/"property-names" during review to
> bring attention to the preferred style (ordering of such entries),
> which is maybe what confused you

Hmm fair. Just thought 'led-names' looks a bit ugly under 'leds'. But
you are right, since there are already "clocks"/"clock-names",
"resets"/"reset-names", lets keep it that way.

Thanks for clarification,

Alex

> 
> Konrad

[PATCH v3 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..703bbc9960dd6bc68baff4f300c77813f5ccd37f 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-led
+
   lens-focus:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:

-- 
2.48.1

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

[Konrad Dybcio]

On 9/8/25 1:18 AM, 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>
> ---

[...]

>  
> +  leds:
> +    minItems: 1
> +    maxItems: 1

My brain compiler suggests this will throw a warning (minItems should
be redundant in this case)
> +
> +  led-names:
> +    enum:
> +      - privacy-led

Nit: "privacy" makes more sense without the suffix, as we inherently
know this is supposed to be an LED

Konrad

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

[Hans de Goede]

Hi,

On 8-Sep-25 09:20, Konrad Dybcio wrote:
> On 9/8/25 1:18 AM, 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>
>> ---
> 
> [...]
> 
>>  
>> +  leds:
>> +    minItems: 1
>> +    maxItems: 1
> 
> My brain compiler suggests this will throw a warning (minItems should
> be redundant in this case)
>> +
>> +  led-names:
>> +    enum:
>> +      - privacy-led
> 
> Nit: "privacy" makes more sense without the suffix, as we inherently
> know this is supposed to be an LED

Note "privacy-led" as name is already used on the x86/ACPI side and
the code consuming this will be shared.

With that said if there is a strong preference for going with just
"privacy" the x86 side can be adjusted since the provider-info is
generated through a LED lookup table on the x86/ACPI side. So we can
just modify both the lookup table generation as well as the already
existing led_get(dev, "privacy-led") call to use just "privacy"
without problems.

Regards,

Hans

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

[Konrad Dybcio]

On 9/8/25 9:33 AM, Hans de Goede wrote:
> Hi,
> 
> On 8-Sep-25 09:20, Konrad Dybcio wrote:
>> On 9/8/25 1:18 AM, 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>
>>> ---
>>
>> [...]
>>
>>>  
>>> +  leds:
>>> +    minItems: 1
>>> +    maxItems: 1
>>
>> My brain compiler suggests this will throw a warning (minItems should
>> be redundant in this case)
>>> +
>>> +  led-names:
>>> +    enum:
>>> +      - privacy-led
>>
>> Nit: "privacy" makes more sense without the suffix, as we inherently
>> know this is supposed to be an LED
> 
> Note "privacy-led" as name is already used on the x86/ACPI side and
> the code consuming this will be shared.
> 
> With that said if there is a strong preference for going with just
> "privacy" the x86 side can be adjusted since the provider-info is
> generated through a LED lookup table on the x86/ACPI side. So we can
> just modify both the lookup table generation as well as the already
> existing led_get(dev, "privacy-led") call to use just "privacy"
> without problems.

In that case, it may be cleaner to just go with what we have today
(unless the dt maintainers have stronger opinions)

Konrad

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

[Aleksandrs Vinarskis]

On Monday, September 8th, 2025 at 09:36, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:

> 
> 
> On 9/8/25 9:33 AM, Hans de Goede wrote:
> 
> > Hi,
> > 
> > On 8-Sep-25 09:20, Konrad Dybcio wrote:
> > 
> > > On 9/8/25 1:18 AM, 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
> > > > ---
> > > 
> > > [...]
> > > 
> > > > + leds:
> > > > + minItems: 1
> > > > + maxItems: 1
> > > 
> > > My brain compiler suggests this will throw a warning (minItems should
> > > be redundant in this case)

No complaints when running `dt_bindings_check` on this nor the camera sensor
that uses this binding. I thought it would be better to keep it even though
right now only one LED is supported, so that when `led-names` are extended
with new functions, one can just bump maxItems and not accidentally forget
to introduce minItems. No strong opinion though, perhaps Rob can decide
since he is the one that suggested to add minItems,maxItems that I didn't
think of?

> > > 
> > > > +
> > > > + led-names:
> > > > + enum:
> > > > + - privacy-led
> > > 
> > > Nit: "privacy" makes more sense without the suffix, as we inherently
> > > know this is supposed to be an LED
> > 
> > Note "privacy-led" as name is already used on the x86/ACPI side and
> > the code consuming this will be shared.
> > 
> > With that said if there is a strong preference for going with just
> > "privacy" the x86 side can be adjusted since the provider-info is
> > generated through a LED lookup table on the x86/ACPI side. So we can
> > just modify both the lookup table generation as well as the already
> > existing led_get(dev, "privacy-led") call to use just "privacy"
> > without problems.
> 
> 
> In that case, it may be cleaner to just go with what we have today
> (unless the dt maintainers have stronger opinions)

Sounds good, thanks both for the feedback.

Alex

> 
> Konrad

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

[Rob Herring]

On Mon, Sep 08, 2025 at 09:36:39AM +0200, Konrad Dybcio wrote:
> On 9/8/25 9:33 AM, Hans de Goede wrote:
> > Hi,
> > 
> > On 8-Sep-25 09:20, Konrad Dybcio wrote:
> >> On 9/8/25 1:18 AM, 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>
> >>> ---
> >>
> >> [...]
> >>
> >>>  
> >>> +  leds:
> >>> +    minItems: 1
> >>> +    maxItems: 1
> >>
> >> My brain compiler suggests this will throw a warning (minItems should
> >> be redundant in this case)
> >>> +
> >>> +  led-names:
> >>> +    enum:
> >>> +      - privacy-led
> >>
> >> Nit: "privacy" makes more sense without the suffix, as we inherently
> >> know this is supposed to be an LED
> > 
> > Note "privacy-led" as name is already used on the x86/ACPI side and
> > the code consuming this will be shared.
> > 
> > With that said if there is a strong preference for going with just
> > "privacy" the x86 side can be adjusted since the provider-info is
> > generated through a LED lookup table on the x86/ACPI side. So we can
> > just modify both the lookup table generation as well as the already
> > existing led_get(dev, "privacy-led") call to use just "privacy"
> > without problems.
> 
> In that case, it may be cleaner to just go with what we have today
> (unless the dt maintainers have stronger opinions)

Well, I do, but I guess it's fine. Please don't add the suffix on the 
rest and add a comment for why it's there.

Rob

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

[Hans de Goede]

Hi,

On 9-Sep-25 12:22 AM, Rob Herring wrote:
> On Mon, Sep 08, 2025 at 09:36:39AM +0200, Konrad Dybcio wrote:
>> On 9/8/25 9:33 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 8-Sep-25 09:20, Konrad Dybcio wrote:
>>>> On 9/8/25 1:18 AM, 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>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>>  
>>>>> +  leds:
>>>>> +    minItems: 1
>>>>> +    maxItems: 1
>>>>
>>>> My brain compiler suggests this will throw a warning (minItems should
>>>> be redundant in this case)
>>>>> +
>>>>> +  led-names:
>>>>> +    enum:
>>>>> +      - privacy-led
>>>>
>>>> Nit: "privacy" makes more sense without the suffix, as we inherently
>>>> know this is supposed to be an LED
>>>
>>> Note "privacy-led" as name is already used on the x86/ACPI side and
>>> the code consuming this will be shared.
>>>
>>> With that said if there is a strong preference for going with just
>>> "privacy" the x86 side can be adjusted since the provider-info is
>>> generated through a LED lookup table on the x86/ACPI side. So we can
>>> just modify both the lookup table generation as well as the already
>>> existing led_get(dev, "privacy-led") call to use just "privacy"
>>> without problems.
>>
>> In that case, it may be cleaner to just go with what we have today
>> (unless the dt maintainers have stronger opinions)
> 
> Well, I do, but I guess it's fine. Please don't add the suffix on the 
> rest and add a comment for why it's there.

Dropping the "-led" suffix on the ACPI side really is no big deal,
so if we don't want the suffix it is probably best to also drop
it for "privacy-led" rather then setting a bad example to be
copy and pasted.

Regards,

Hans

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

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

Hi All,

On 9-Sep-25 12:22 AM, Rob Herring wrote:
> On Mon, Sep 08, 2025 at 09:36:39AM +0200, Konrad Dybcio wrote:
>> On 9/8/25 9:33 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 8-Sep-25 09:20, Konrad Dybcio wrote:
>>>> On 9/8/25 1:18 AM, 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>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>>  
>>>>> +  leds:
>>>>> +    minItems: 1
>>>>> +    maxItems: 1
>>>>
>>>> My brain compiler suggests this will throw a warning (minItems should
>>>> be redundant in this case)
>>>>> +
>>>>> +  led-names:
>>>>> +    enum:
>>>>> +      - privacy-led
>>>>
>>>> Nit: "privacy" makes more sense without the suffix, as we inherently
>>>> know this is supposed to be an LED
>>>
>>> Note "privacy-led" as name is already used on the x86/ACPI side and
>>> the code consuming this will be shared.
>>>
>>> With that said if there is a strong preference for going with just
>>> "privacy" the x86 side can be adjusted since the provider-info is
>>> generated through a LED lookup table on the x86/ACPI side. So we can
>>> just modify both the lookup table generation as well as the already
>>> existing led_get(dev, "privacy-led") call to use just "privacy"
>>> without problems.
>>
>> In that case, it may be cleaner to just go with what we have today
>> (unless the dt maintainers have stronger opinions)
> 
> Well, I do, but I guess it's fine. Please don't add the suffix on the 
> rest and add a comment for why it's there.

As mentioned dropping the "-led" suffix is no big deal for the ACPI
side and if we don't want the suffix then IMHO we should just drop
it rather then making an exception here.

Attached are 2 patches which drop the suffix on the ACPI side.

If people agree with dropping the suffix I'll officially submit these
upstream.

Regards,

Hans

[-- Attachment #2: 0001-platform-x86-int3472-Use-privacy-as-con_id-for-the-L.patch --]
[-- Type: text/x-patch, Size: 1446 bytes --]

From d98d60b0b8c13fc3ea65159265c21c7bb359e605 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hansg@kernel.org>
Date: Tue, 9 Sep 2025 11:09:37 +0200
Subject: [PATCH 1/2] platform/x86: int3472: Use "privacy" as con_id for the
 LED lookup

During DT-binding review for extending the V4L2 camera sensor privacy LED
support to systems using devicetree, it has come up that having a "-led"
suffix for the LED name / con_id is undesirable since it already is clear
that it is a LED.

Drop the "-led" suffix from the privacy LED's lookup table con_id.

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Note this needs to be merged in the same kernel cycle as the matching
"media: v4l2-subdev: Use "privacy" as con_id when getting the privacy LED"
patch.
---
 drivers/platform/x86/intel/int3472/led.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel/int3472/led.c b/drivers/platform/x86/intel/int3472/led.c
index f1d6d7b0cb75..b1d84b968112 100644
--- a/drivers/platform/x86/intel/int3472/led.c
+++ b/drivers/platform/x86/intel/int3472/led.c
@@ -43,7 +43,7 @@ int skl_int3472_register_pled(struct int3472_discrete_device *int3472, struct gp
 
 	int3472->pled.lookup.provider = int3472->pled.name;
 	int3472->pled.lookup.dev_id = int3472->sensor_name;
-	int3472->pled.lookup.con_id = "privacy-led";
+	int3472->pled.lookup.con_id = "privacy";
 	led_add_lookup(&int3472->pled.lookup);
 
 	return 0;
-- 
2.51.0


[-- Attachment #3: 0002-media-v4l2-subdev-Use-privacy-as-con_id-when-getting.patch --]
[-- Type: text/x-patch, Size: 1503 bytes --]

From 02dce3eec34cd8b894fc5fef009a6e302f58c2f3 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hansg@kernel.org>
Date: Tue, 9 Sep 2025 11:14:34 +0200
Subject: [PATCH 2/2] media: v4l2-subdev: Use "privacy" as con_id when getting
 the privacy LED

During DT-binding review for extending the V4L2 camera sensor privacy LED
support to systems using devicetree, it has come up that having a "-led"
suffix for the LED name / con_id is undesirable since it already is clear
that it is a LED.

Drop the "-led" suffix from the con_id argument to led_get().

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Note this needs to be merged in the same kernel cycle as the matching
"platform/x86: int3472: Use "privacy" as con_id for the LED lookup"
patch.
---
 drivers/media/v4l2-core/v4l2-subdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 113eb74eb7c1..babcc1120354 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -2602,7 +2602,7 @@ EXPORT_SYMBOL_GPL(v4l2_subdev_is_streaming);
 int v4l2_subdev_get_privacy_led(struct v4l2_subdev *sd)
 {
 #if IS_REACHABLE(CONFIG_LEDS_CLASS)
-	sd->privacy_led = led_get(sd->dev, "privacy-led");
+	sd->privacy_led = led_get(sd->dev, "privacy");
 	if (IS_ERR(sd->privacy_led) && PTR_ERR(sd->privacy_led) != -ENOENT)
 		return dev_err_probe(sd->dev, PTR_ERR(sd->privacy_led),
 				     "getting privacy LED\n");
-- 
2.51.0

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

[Aleksandrs Vinarskis]

On Tuesday, September 9th, 2025 at 11:21, Hans de Goede <hansg@kernel.org> wrote:

> 
> 
> Hi All,
> 
> On 9-Sep-25 12:22 AM, Rob Herring wrote:
> 
> > On Mon, Sep 08, 2025 at 09:36:39AM +0200, Konrad Dybcio wrote:
> > 
> > > On 9/8/25 9:33 AM, Hans de Goede wrote:
> > > 
> > > > Hi,
> > > > 
> > > > On 8-Sep-25 09:20, Konrad Dybcio wrote:
> > > > 
> > > > > On 9/8/25 1:18 AM, 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
> > > > > > ---
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > + leds:
> > > > > > + minItems: 1
> > > > > > + maxItems: 1
> > > > > 
> > > > > My brain compiler suggests this will throw a warning (minItems should
> > > > > be redundant in this case)
> > > > > 
> > > > > > +
> > > > > > + led-names:
> > > > > > + enum:
> > > > > > + - privacy-led
> > > > > 
> > > > > Nit: "privacy" makes more sense without the suffix, as we inherently
> > > > > know this is supposed to be an LED
> > > > 
> > > > Note "privacy-led" as name is already used on the x86/ACPI side and
> > > > the code consuming this will be shared.
> > > > 
> > > > With that said if there is a strong preference for going with just
> > > > "privacy" the x86 side can be adjusted since the provider-info is
> > > > generated through a LED lookup table on the x86/ACPI side. So we can
> > > > just modify both the lookup table generation as well as the already
> > > > existing led_get(dev, "privacy-led") call to use just "privacy"
> > > > without problems.
> > > 
> > > In that case, it may be cleaner to just go with what we have today
> > > (unless the dt maintainers have stronger opinions)
> > 
> > Well, I do, but I guess it's fine. Please don't add the suffix on the
> > rest and add a comment for why it's there.
> 
> 
> As mentioned dropping the "-led" suffix is no big deal for the ACPI
> side and if we don't want the suffix then IMHO we should just drop
> it rather then making an exception here.
> 
> Attached are 2 patches which drop the suffix on the ACPI side.
> 
> If people agree with dropping the suffix I'll officially submit these
> upstream.

Sounds like this is the preferred way. Could you please CC me when you
submit it? I will then respin this series and indicate yours as
dependency.

Thanks,
Alex

> 
> Regards,
> 
> Hans

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

[Hans de Goede]

Hi,

On 9-Sep-25 11:28 AM, Aleksandrs Vinarskis wrote:
> 
> 
> 
> 
> 
> On Tuesday, September 9th, 2025 at 11:21, Hans de Goede <hansg@kernel.org> wrote:
> 
>>
>>
>> Hi All,
>>
>> On 9-Sep-25 12:22 AM, Rob Herring wrote:
>>
>>> On Mon, Sep 08, 2025 at 09:36:39AM +0200, Konrad Dybcio wrote:
>>>
>>>> On 9/8/25 9:33 AM, Hans de Goede wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 8-Sep-25 09:20, Konrad Dybcio wrote:
>>>>>
>>>>>> On 9/8/25 1:18 AM, 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
>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> + leds:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 1
>>>>>>
>>>>>> My brain compiler suggests this will throw a warning (minItems should
>>>>>> be redundant in this case)
>>>>>>
>>>>>>> +
>>>>>>> + led-names:
>>>>>>> + enum:
>>>>>>> + - privacy-led
>>>>>>
>>>>>> Nit: "privacy" makes more sense without the suffix, as we inherently
>>>>>> know this is supposed to be an LED
>>>>>
>>>>> Note "privacy-led" as name is already used on the x86/ACPI side and
>>>>> the code consuming this will be shared.
>>>>>
>>>>> With that said if there is a strong preference for going with just
>>>>> "privacy" the x86 side can be adjusted since the provider-info is
>>>>> generated through a LED lookup table on the x86/ACPI side. So we can
>>>>> just modify both the lookup table generation as well as the already
>>>>> existing led_get(dev, "privacy-led") call to use just "privacy"
>>>>> without problems.
>>>>
>>>> In that case, it may be cleaner to just go with what we have today
>>>> (unless the dt maintainers have stronger opinions)
>>>
>>> Well, I do, but I guess it's fine. Please don't add the suffix on the
>>> rest and add a comment for why it's there.
>>
>>
>> As mentioned dropping the "-led" suffix is no big deal for the ACPI
>> side and if we don't want the suffix then IMHO we should just drop
>> it rather then making an exception here.
>>
>> Attached are 2 patches which drop the suffix on the ACPI side.
>>
>> If people agree with dropping the suffix I'll officially submit these
>> upstream.
> 
> Sounds like this is the preferred way. Could you please CC me when you
> submit it? I will then respin this series and indicate yours as
> dependency.

Done, including adding you to the Cc.

Regards,

Hans

[PATCH v3 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 v3 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..ef5c7cbeda68c7eb4745cd2ec01eaacf9a83040a 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-led";
+
 		clocks = <&camcc CAMCC_MCLK3_CLK>;
 
 		orientation = <0>;	/* Front facing */

-- 
2.48.1