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) Konrad
