On Mon, Sep 08, 2025 at 09:36:39AM +0200, Konrad Dybcio wrote:

On 9/8/25 9:33 AM, Hans de Goede wrote:

quoted

Hi,

On 8-Sep-25 09:20, Konrad Dybcio wrote:

quoted

On 9/8/25 1:18 AM, Aleksandrs Vinarskis wrote:

quoted

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

[...]

quoted

 
+  leds:
+    minItems: 1
+    maxItems: 1

My brain compiler suggests this will throw a warning (minItems should
be redundant in this case)

quoted

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