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 <a...@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
