From: Jacek Anaszewski [mailto:jacek.anaszewski@xxxxxxxxx] Sent: Monday, December 5, 2022 7:44 PM > > Hi all, > Hi all, > On 12/2/22 00:41, Marek Vasut wrote: >> On 11/30/22 20:19, Rob Herring wrote: >>> On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: >>>> On 11/22/22 13:23, Pavel Machek wrote: >>>>> Hi! >>>> >>>> Hi, >>>> >>>>>> Mark the label property as deprecated as it is mentioned >>>>>> in the description. >>>>> >>>>> Lets do it the other way around. Functions (etc) don't really provide >>>>> good enough description of LED, and label is still needed. >>>> >>>> Can you please provide a clear explanation which property or approach >>>> is the >>>> correct one for new DTs ? >>>> >>>> So far, the documentation states that "label" is deprecated, and users >>>> should replace it with "function" and "color". >>> >>> 'function' is what activity/operation the LED is associated with. It is >>> a fixed set of strings which s/w may use. It is a replacement for >>> 'linux,default-trigger'. >> >> Isn't this 'function' more of a standardized replacement for 'label' ? > > Yes it is. Introduction of function and color properties aimed at > standardizing LED naming. Before there was only 'label' used for that, > with DT node name as fallback if 'label' property was not provided. > With introduction of 'function' and 'color' label was deprecated in > the sense that if the former two are present, they are used for > composing the LED name. > > In LED documentation [0] people are encouraged to use definitions from > include/dt-bindings/leds/common.h to keep LED naming uniform. > It allows to avoid duplicates like "wlan" and "wifi". > >> $ git grep LED_FUNCTION_ include/ >> ... >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_PLAYER5 "player-5" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_ACTIVITY "activity" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_ALARM "alarm" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BACKLIGHT >> "backlight" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BLUETOOTH >> "bluetooth" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BOOT "boot" >> ... >> >> Seems to me that ^ is closer to a "standardized" form of 'label' . >> >> The LED subsystem does not infer any behavior of those LEDs based on >> their 'function' property as far as I can tell, at least not in the way >> 'linux,default-trigger' behaves. >> >>> 'label' is what is printed next to the LED for a human to read. 'label' >>> can be anything and the OS shouldn't care what it is. >> >> This part I understand. What is not clear to me is, why is 'label' being >> un-deprecated. > > It shouldn't be. It seems to be Pavel's ad-hoc decision. Is there a majority agreement that the "label" property remains deprecated? If so, I would say we can mark the label as deprecated. On the other hand, the new generated standardized sysfs name does not seem to provide a full replacement for the "label" property. What is still missing? How can the current state be extended to find more acceptance? [...] Regards Christoph
