From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Olliver Schinagl <oliver@schinagl.nl>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Baolin Wang <baolin.wang@linaro.org>,
Daniel Mack <daniel@zonque.org>,
Linus Walleij <linus.walleij@linaro.org>,
Oleh Kravchenko <oleg@kaa.org.ua>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Simon Shields <simon@lineageos.org>,
Olliver Schinagl <oliver+list@schinagl.nl>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 resend] dt-bindings: leds: Expand LED_COLOR_ID definitions
Date: Tue, 30 Aug 2022 12:28:35 +0200 [thread overview]
Message-ID: <44eec926-b7d0-f8eb-f944-d28e3b35257a@gmail.com> (raw)
In-Reply-To: <20220819152904.433514-1-oliver@schinagl.nl>
Hi Oliver,
On 8/19/22 17:29, Olliver Schinagl wrote:
> In commit 853a78a7d6c7 (dt-bindings: leds: Add LED_COLOR_ID definitions,
> Sun Jun 9 20:19:04 2019 +0200) the most basic color definitions where
> added. However, there's a little more very common LED colors.
>
> While the documentation states 'add what is missing', engineers tend to
> be lazy and will just use what currently exists. So this patch will take
> (a) list from online retailers [0], [1], [2] and use the common LED colors
> from there, this being reasonable as this is what is currently available to
> purchase.
>
> Note, that LIME seems to be the modern take to 'Yellow-green' or
> 'Yellowish-green' from some older datasheets.
>
> [0]: https://www.digikey.com/en/products/filter/led-lighting-color/125
> [1]: https://eu.mouser.com/c/optoelectronics/led-lighting/led-emitters/standard-leds-smd
> [2]: https://nl.farnell.com/en-NL/c/optoelectronics-displays/led-products/standard-single-colour-leds-under-75ma
>
> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
> ---
>
> Changes since v1: Unbreak existing definitions.
>
>
> include/dt-bindings/leds/common.h | 28 ++++++++++++++++------------
> 1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
> index 3be89a7c20a9..04bf94523ea3 100644
> --- a/include/dt-bindings/leds/common.h
> +++ b/include/dt-bindings/leds/common.h
> @@ -22,18 +22,22 @@
> #define LEDS_BOOST_FIXED 2
>
> /* Standard LED colors */
> -#define LED_COLOR_ID_WHITE 0
> -#define LED_COLOR_ID_RED 1
> -#define LED_COLOR_ID_GREEN 2
> -#define LED_COLOR_ID_BLUE 3
> -#define LED_COLOR_ID_AMBER 4
> -#define LED_COLOR_ID_VIOLET 5
> -#define LED_COLOR_ID_YELLOW 6
> -#define LED_COLOR_ID_IR 7
> -#define LED_COLOR_ID_MULTI 8 /* For multicolor LEDs */
> -#define LED_COLOR_ID_RGB 9 /* For multicolor LEDs that can do arbitrary color,
> - so this would include RGBW and similar */
> -#define LED_COLOR_ID_MAX 10
> +#define LED_COLOR_ID_WHITE 0
> +#define LED_COLOR_ID_RED 1
> +#define LED_COLOR_ID_GREEN 2
> +#define LED_COLOR_ID_BLUE 3
> +#define LED_COLOR_ID_AMBER 4
> +#define LED_COLOR_ID_VIOLET 5
> +#define LED_COLOR_ID_YELLOW 6
> +#define LED_COLOR_ID_IR 7
> +#define LED_COLOR_ID_MULTI 8 /* For multicolor LEDs */
> +#define LED_COLOR_ID_RGB 9 /* For multicolor LEDs that can do arbitrary color, including RGBW etc. */
> +#define LED_COLOR_ID_PUPRPLE 10
typo - as already mentioned
> +#define LED_COLOR_ID_ORANGE 11
> +#define LED_COLOR_ID_PINK 12
> +#define LED_COLOR_ID_CYAN 13
> +#define LED_COLOR_ID_LIME 14
> +#define LED_COLOR_ID_MAX 15
>
> /* Standard LED functions */
> /* Keyboard LEDs, usually it would be input4::capslock etc. */
And it seems that change in spacing between definition name and value
is not required, is it? Without that change, it would be easier to
notice what really changes here.
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2022-08-30 10:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 15:29 [PATCHv2 resend] dt-bindings: leds: Expand LED_COLOR_ID definitions Olliver Schinagl
2022-08-23 10:33 ` Krzysztof Kozlowski
2022-08-29 14:12 ` Alexander Dahl
2022-08-29 15:13 ` Rob Herring
2022-08-30 8:30 ` Olliver Schinagl
2022-08-30 8:37 ` Krzysztof Kozlowski
2022-08-30 10:28 ` Jacek Anaszewski [this message]
2022-08-30 13:40 ` Olliver Schinagl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44eec926-b7d0-f8eb-f944-d28e3b35257a@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=baolin.wang@linaro.org \
--cc=daniel@zonque.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@kaa.org.ua \
--cc=oliver+list@schinagl.nl \
--cc=oliver@schinagl.nl \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=simon@lineageos.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).