[v3] leds: privacy-led support for devicetree

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

Posted by Aleksandrs Vinarskis 1 day, 22 hours ago

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

Posted by Konrad Dybcio 1 day, 14 hours ago

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

Posted by Hans de Goede 1 day, 14 hours ago

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

Posted by Konrad Dybcio 1 day, 13 hours ago

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

Posted by Rob Herring 23 hours ago

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

Posted by Hans de Goede 12 hours ago

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

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

Posted by Aleksandrs Vinarskis 12 hours ago





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

Posted by Hans de Goede 6 hours ago

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

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

Posted by Hans de Goede 12 hours ago

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

Posted by Aleksandrs Vinarskis 1 day, 10 hours ago





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