From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Dan Murphy <dmurphy@ti.com>, rpurdie@rpsys.net, pavel@ucw.cz
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/6] leds: Add new API to derive a LED name
Date: Sun, 3 Dec 2017 14:27:01 +0100 [thread overview]
Message-ID: <1c6f0b40-7790-ae94-a65c-d6765c60e4f0@gmail.com> (raw)
In-Reply-To: <20171201165613.10358-1-dmurphy@ti.com>
Dan,
On 12/01/2017 05:56 PM, Dan Murphy wrote:
> Create an API that is called to derive the
> LED name from either the DT label in the child
> node or if that does not exist from the parent
> node name and an alternate label that is passed in.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v6 - New patch to add the api to generate a LED label
>
> drivers/leds/led-class.c | 34 ++++++++++++++++++++++++++++++++++
> include/linux/leds.h | 6 ++++++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index b0e2d55acbd6..d3e035488737 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -17,6 +17,7 @@
> #include <linux/leds.h>
> #include <linux/list.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> #include <linux/timer.h>
> @@ -243,6 +244,39 @@ static int led_classdev_next_name(const char *init_name, char *name,
> return i;
> }
>
> +/**
> + * of_led_compose_name - derive the LED name based on DT or alternate name.
> + *
> + * @parent: parent of LED device
> + * @child: child node of LED device
> + * @alt_name: an alternate name if the label node is not found
> + * @len: length of the alt_name
> + * @led_name: derived name from either DT label or alt_name
> + */
> +void of_led_compose_name(struct device_node *parent,
> + struct device_node *child,
> + const char *alt_name,
> + size_t len,
> + char *led_name)
> +{
> + int ret;
> + int length;
> + const char *name;
> +
> + if (len == 0 || alt_name == NULL)
> + return;
> +
> + ret = of_property_read_string(child, "label", &name);
> + if (!ret) {
> + strlcpy(led_name, name, sizeof(led_name));
> + } else {
> + length = len + strlen(parent->name) + 1;
> + snprintf(led_name, len, "%s:%s", parent->name, alt_name);
> + }
It looks different from what I meant, i.e. that devicename
segment shouldn't be present in the label, but derived
from the parent DT node name.
This is however to be decided whether it wouldn't be better to leave
the decision to the driver on how to obtain devicename - from parent
DT node or from the driver hardcoded string. Some LED class drivers
prefer the latter way, so if their parent node name differs a bit from
the string they currently use for devicename, then the resulting
LED class device name will change after switching to using this
new API. In order to avoid that we would have to modify related
DT node names in *.dts files, which would make unnecessary noise.
Since it may take a while to agree on the final semantics
of this new API, especially after my recent patch [0], I propose
to put below piece of code directly in the driver:
ret = of_property_read_string(child_node, "label", &name);
if (!ret)
snprintf(led->label, sizeof(led->label), "%s:%s",
np->name, name)
else
snprintf(led->label, sizeof(led->label),
"%s::%s", np->name, name)
Please note that "::" means leaving colour section blank,
because we don't know the LED colour if label DT property was not
provided.
> +}
> +EXPORT_SYMBOL_GPL(of_led_compose_name);
> +
> /**
> * of_led_classdev_register - register a new object of led_classdev class.
> *
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 5579c64c8fd6..9e18dbe196e2 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -123,6 +123,12 @@ struct led_classdev {
> struct mutex led_access;
> };
>
> +extern void of_led_compose_name(struct device_node *parent,
> + struct device_node *child,
> + const char *alt_name,
> + size_t len,
> + char *led_name);
> +
> extern int of_led_classdev_register(struct device *parent,
> struct device_node *np,
> struct led_classdev *led_cdev);
>
[0] https://patchwork.kernel.org/patch/10089047
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2017-12-03 13:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 16:56 [PATCH v6 1/6] leds: Add new API to derive a LED name Dan Murphy
2017-12-01 16:56 ` [PATCH v6 2/6] dt: bindings: lm3692x: Add bindings for lm3692x LED driver Dan Murphy
2017-12-01 16:56 ` [PATCH v6 3/6] leds: lm3692x: Introduce LM3692x dual string driver Dan Murphy
2017-12-01 16:56 ` [PATCH v6 4/6] dt: bindings: lp8860: Update the bindings to the standard Dan Murphy
[not found] ` <20171201165613.10358-4-dmurphy-l0cyMroinI0@public.gmane.org>
2017-12-03 13:27 ` Jacek Anaszewski
2017-12-04 22:35 ` Rob Herring
2017-12-05 13:06 ` Dan Murphy
2017-12-03 13:49 ` Jacek Anaszewski
2017-12-03 14:34 ` Jacek Anaszewski
2017-12-01 16:56 ` [PATCH v6 5/6] leds: lp8860: Update the LED label generation Dan Murphy
2017-12-01 16:59 ` Dan Murphy
2017-12-03 14:00 ` Jacek Anaszewski
2017-12-03 13:57 ` Jacek Anaszewski
2017-12-04 13:11 ` Dan Murphy
2017-12-05 19:56 ` Jacek Anaszewski
2017-12-05 19:59 ` Dan Murphy
2017-12-01 16:56 ` [PATCH v6 6/6] leds: as3645a: " Dan Murphy
2017-12-01 16:58 ` Dan Murphy
2017-12-03 13:27 ` Jacek Anaszewski [this message]
2017-12-04 13:09 ` [PATCH v6 1/6] leds: Add new API to derive a LED name Dan Murphy
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=1c6f0b40-7790-ae94-a65c-d6765c60e4f0@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rpurdie@rpsys.net \
/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).