On 03/04/2024 10:31, Hans de Goede wrote: > Hi Krzysztof, > > On 4/2/24 3:55 PM, Krzysztof Kozlowski wrote: >> On 02/04/2024 15:21, Gergo Koteles wrote: >>> Newer laptops have FnLock LED. >>> >>> Add a define for this very common function. >>> >>> Signed-off-by: Gergo Koteles <soyer@xxxxxx> >>> --- >>> include/dt-bindings/leds/common.h | 1 + >> >> Do we really need to define all these possible LED functions? Please >> link to DTS user for this. > > It is useful to have well established names for common > LED functions instead of having each driver come up > with its own name with slightly different spelling > for various fixed function LEDs. > > This is even documented in: > > Documentation/leds/leds-class.rst : > > """ > LED Device Naming > ================= > > Is currently of the form: > > "devicename:color:function" > > ... > > > - function: > one of LED_FUNCTION_* definitions from the header > include/dt-bindings/leds/common.h. > """ > > Note this even specifies these definitions should go into > include/dt-bindings/leds/common.h . > > In this case there is no dts user (yet) only an in kernel > driver which wants to use a LED_FUNCTION_* define to > establish how to identify FN-lock LEDs going forward. Ack, reasonable. > > Since a lot of LED_FUNCTION_* defines happen to be used > in dts files these happen to live under include/dt-bindings/ > but the dts files are not the only consumer of these defines (1). Yes, but if there was no DTS consumer at all, then it is not a binding, so it should not go to include/dt-bindings. > > IMHO having a hard this must be used in a dts file rule > is not helpful for these kinda files with defines shared > between dts and non dts cases. > > If we were to follow this logic then any addition to > > include/uapi/linux/input-event-codes.h > > must have a dts user before being approved too ? Since > that file is included from include/dt-bindings/input/input.h ? Wait, that's UAPI :) and we just share the constants. That's kind of special case, but I get what you mean. > > TL;DR: not only is this patch fine, this is actually > the correct place to add such a define according to > the docs in Documentation/leds/leds-class.rst : > > Reviewed-by: Hans de Goede <hdegoede@xxxxxxxxxx> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> Best regards, Krzysztof
