From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Nicolas Belin <nbelin@baylibre.com>,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
pavel@ucw.cz, dmurphy@ti.com, devicetree@vger.kernel.org
Cc: baylibre-upstreaming@groups.io
Subject: Re: [PATCH RFC v2 3/3] drivers: leds: add support for apa102c leds
Date: Wed, 26 Feb 2020 21:13:58 +0100 [thread overview]
Message-ID: <85f536f0-0078-08a5-5eeb-e401d1ed8782@gmail.com> (raw)
In-Reply-To: <1582727592-4510-4-git-send-email-nbelin@baylibre.com>
Hi Nicolas,
Regardless of the fact that LED mc framework in current shape
will probably not materialize in mainline, I have single
remark regarding LED initialization. Please take a look below.
On 2/26/20 3:33 PM, Nicolas Belin wrote:
> Initilial commit in order to support the apa102c RGB leds. This
> is based on the Multicolor Framework.
>
> Reviewed-by: Corentin Labbe <clabbe@baylibre.com>
> Signed-off-by: Nicolas Belin <nbelin@baylibre.com>
> ---
> drivers/leds/Kconfig | 7 ++
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-apa102c.c | 291 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 299 insertions(+)
> create mode 100644 drivers/leds/leds-apa102c.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 5dc6535a88ef..71e29727c6ec 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -79,6 +79,13 @@ config LEDS_AN30259A
> To compile this driver as a module, choose M here: the module
> will be called leds-an30259a.
>
> +config LEDS_APA102C
> + tristate "LED Support for Shiji APA102C"
> + depends on SPI
> + depends on LEDS_CLASS_MULTI_COLOR
> + help
> + This option enables support for APA102C LEDs.
> +
> config LEDS_APU
> tristate "Front panel LED support for PC Engines APU/APU2/APU3 boards"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index b5305b7d43fb..8334cb6dc7e8 100644
[...]
> +
> + led->priv = priv;
> + led->ldev.max_brightness = MAX_BRIGHTNESS;
> + fwnode_property_read_string(child, "linux,default-trigger",
> + &led->ldev.default_trigger);
> +
> + init_data.fwnode = child;
> + init_data.devicename = APA_DEV_NAME;
> + init_data.default_label = ":";
devicename property should be filled in new drivers only in case
devname_mandatory is set to true.
default_label property is for legacy drivers, for backward compatibility
with old LED naming convention.
For more information please refer to:
- Documentation/leds/leds-class.rst, "LED Device Naming" section
- struct led_init_data documention in linux/leds.h
In effect you need only fwnode here,
> +
> + num_colors = 0;
> + fwnode_for_each_child_node(child, grandchild) {
> + ret = fwnode_property_read_u32(grandchild, "color",
> + &color_id);
> + if (ret) {
> + dev_err(priv->dev, "Cannot read color\n");
> + goto child_out;
> + }
> +
> + set_bit(color_id, &led->mc_cdev.available_colors);
> + num_colors++;
> + }
> +
> + if (num_colors != 3) {
> + ret = -EINVAL;
> + dev_err(priv->dev, "There should be 3 colors\n");
> + goto child_out;
> + }
> +
> + if (led->mc_cdev.available_colors != IS_RGB) {
> + ret = -EINVAL;
> + dev_err(priv->dev, "The led is expected to be RGB\n");
> + goto child_out;
> + }
> +
> + led->mc_cdev.num_leds = num_colors;
> + led->mc_cdev.led_cdev = &led->ldev;
> + led->ldev.brightness_set_blocking = apa102c_brightness_set;
> + ret = devm_led_classdev_multicolor_register_ext(priv->dev,
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2020-02-26 20:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 14:33 [PATCH RFC v2 0/3] leds: add support for apa102c leds Nicolas Belin
2020-02-26 14:33 ` [PATCH RFC v2 1/3] dt-bindings: Document shiji vendor-prefix Nicolas Belin
2020-03-03 14:29 ` Rob Herring
2020-02-26 14:33 ` [PATCH RFC v2 2/3] dt-bindings: leds: Shiji Lighting APA102C LED driver Nicolas Belin
2020-02-26 21:56 ` Rob Herring
2020-02-26 14:33 ` [PATCH RFC v2 3/3] drivers: leds: add support for apa102c leds Nicolas Belin
2020-02-26 20:13 ` Jacek Anaszewski [this message]
2020-03-03 10:30 ` Nicolas Belin
2020-03-03 19:37 ` Jacek Anaszewski
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=85f536f0-0078-08a5-5eeb-e401d1ed8782@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=baylibre-upstreaming@groups.io \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=nbelin@baylibre.com \
--cc=pavel@ucw.cz \
/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).