| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <232b6154-cccd-c1f9-80c3-438098f3ab08@gmail.com>
Date: Tue, 12 Mar 2019 17:43:11 +0100
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Dan Murphy <dmurphy@...com>, linux-leds@...r.kernel.org
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
pavel@....cz, robh@...nel.org,
Baolin Wang <baolin.wang@...aro.org>,
Daniel Mack <daniel@...que.org>,
Linus Walleij <linus.walleij@...aro.org>,
Oleh Kravchenko <oleg@....org.ua>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Simon Shields <simon@...eageos.org>
Subject: Re: [PATCH 05/25] dt-bindings: leds: Add function and color
properties
On 3/11/19 6:24 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 3/11/19 1:26 PM, Dan Murphy wrote:
>> On 3/10/19 1:28 PM, Jacek Anaszewski wrote:
>>> Introduce dedicated properties for conveying information about
>>> LED function and color. Mark old "label" property as deprecated.
>>>
>>> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@...il.com>
>>> Cc: Baolin Wang <baolin.wang@...aro.org>
>>> Cc: Daniel Mack <daniel@...que.org>
>>> Cc: Dan Murphy <dmurphy@...com>
>>> Cc: Linus Walleij <linus.walleij@...aro.org>
>>> Cc: Oleh Kravchenko <oleg@....org.ua>
>>> Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>
>>> Cc: Simon Shields <simon@...eageos.org>
>>> ---
>>> Documentation/devicetree/bindings/leds/common.txt | 55
>>> +++++++++++++++++++----
>>> 1 file changed, 47 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt
>>> b/Documentation/devicetree/bindings/leds/common.txt
>>> index aa1399814a2a..3402b0e1cec9 100644
>>> --- a/Documentation/devicetree/bindings/leds/common.txt
>>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>>> @@ -10,14 +10,23 @@ can influence the way of the LED device
>>> initialization, the LED components
>>> have to be tightly coupled with the LED device binding. They are
>>> represented
>>> by child nodes of the parent LED device binding.
>>> +
>>> Optional properties for child nodes:
>>> - led-sources : List of device current outputs the LED is connected
>>> to. The
>>> outputs are identified by the numbers that must be defined
>>> in the LED device binding documentation.
>>> +- function: LED functon. Use one of the LED_FUNCTION_* prefixed
>>> definitions
>>> + from the header include/dt-bindings/leds/common.h.
>>> + If there is no matching LED_FUNCTION available, add a new one.
>>> +- color : Color of the LED. Use one of the LED_COLOR_NAME_* prefixed
>>> definitions
>>> + from the header include/dt-bindings/leds/common.h.
>>> + If there is no matching LED_COLOR_NAME available, add a new
>>> one.
>>> +
>>
>> I am assuming multi color can re-use this property as well?
>
> I intended it to be a string, but indeed it would be better if we will
> make it an integer to be consistent with the discussed LED multi color
> design.
Going further, I wonder if it would make sense to make function also
an integer. This way we could enforce use of LED functions known
to kernel.
Additionally, if we introduced a property like function-enum-val
(better name suggestions are welcome), then we could easily solve the
problem of string concatenation limitation in dtc compiler mentioned
in the cover letter, since the concatenation would be done in the LED core.
>>> - label : The label for this LED. If omitted, the label is taken
>>> from the node
>>> name (excluding the unit address). It has to uniquely identify
>>> a device, i.e. no other LED class device can be assigned the
>>> same
>>> - label.
>>> + label. This property is deprecated - use 'function' and 'color'
>>> + properties instead.
>>> - default-state : The initial state of the LED. Valid values are
>>> "on", "off",
>>> and "keep". If the LED is already on or off and the default-state
>>> property is
>>> @@ -87,29 +96,59 @@ Required properties for trigger source:
>>> * Examples
>>> -gpio-leds {
>>> +#include <dt-bindings/leds/common.h>
>>> +
>>> +led-controller@0 {
>>> compatible = "gpio-leds";
>>> - system-status {
>>> - label = "Status";
>>> + led0 {
>>> + function = LED_FUNCTION_STATUS;
>>
>> Missing color for example unless there is a reason to omit it for GPIO
>> LEDs
>
> It is on purpose - to show that it is an optional property for
> monochrome LEDs.
>
>>
>> Also missing reg here
>
> Also on purpose. leds-gpio bindings don't require reg here.
> And when reg is absent the unit address in the node name should
> be omitted as Rob stated in one of recent reviews.
>
>>> linux,default-trigger = "heartbeat";
>>> gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
>>> };
>>> - usb {
>>> + led1 {
>>> + function = LED_FUNCTION_USB;
>>
>> Same as above
>> Also missing reg here
>>> gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
>>> trigger-sources = <&ohci_port1>, <&ehci_port1>;
>>> };
>>> };
>>> -max77693-led {
>>> +led-controller@0 {
>>> compatible = "maxim,max77693-led";
>>> - camera-flash {
>>> - label = "Flash";
>>> + led {
>>> + function = LED_FUNCTION_FLASH;
>>> + color = LED_COLOR_NAME_WHITE;
>>> led-sources = <0>, <1>;
>>> led-max-microamp = <50000>;
>>> flash-max-microamp = <320000>;
>>> flash-max-timeout-us = <500000>;
>>> };
>>> };
>>> +
>>> +led-controller@30 {
>>> + compatible = "panasonic,an30259a";
>>> + reg = <0x30>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + led@1 {
>>> + reg = <1>;
>>> + linux,default-trigger = "heartbeat";
>>> + function = LED_FUNCTION_INDICATOR;
>>> + color = LED_COLOR_NAME_RED;
>>> + };
>>> +
>>> + led@2 {
>>> + reg = <2>;
>>> + function = LED_FUNCTION_INDICATOR;
>>> + color = LED_COLOR_NAME_GREEN;
>>> + };
>>> +
>>> + led@3 {
>>> + reg = <3>;
>>> + function = LED_FUNCTION_INDICATOR;
>>> + color = LED_COLOR_NAME_BLUE;
>>> + };
>>> +};
>>>
>>
>>
>
--
Best regards,
Jacek Anaszewski
Powered by blists - more mailing lists