Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK

[Krzysztof Kozlowski]

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