Hi,

On 9-Sep-25 11:28 AM, Aleksandrs Vinarskis wrote:
> 
> 
> 
> 
> 
> On Tuesday, September 9th, 2025 at 11:21, Hans de Goede <[email protected]> 
> 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 [email protected]
>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> + 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

Reply via email to