Hi, On 4/3/24 10:36 AM, Krzysztof Kozlowski wrote: > 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> Thanks. Is it ok for me to merge this through the pdx86 tree (once I've reviewed the other 2 patches) ? Regards, Hans
