[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17a700a7-44f0-4e46-9a0c-4c2da44c9e27@linaro.org>
Date: Wed, 3 Apr 2024 10:46:04 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Hans de Goede <hdegoede@...hat.com>, Gergo Koteles <soyer@....hu>,
Ike Panhc <ike.pan@...onical.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
On 03/04/2024 10:39, Hans de Goede wrote:
>>>
>>> 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@...hat.com>
>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>
> Thanks. Is it ok for me to merge this through the pdx86
> tree (once I've reviewed the other 2 patches) ?
You need to sync (ack) with LED folks, because by default this should go
via LED subsystem.
Best regards,
Krzysztof
Powered by blists - more mailing lists