From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Tony Lindgren <tony@atomide.com>,
kernel list <linux-kernel@vger.kernel.org>,
sre@kernel.org, nekit1000@gmail.com, mpartap@gmx.net,
merlijn@wizzup.org, Dan Murphy <dmurphy@ti.com>,
linux-leds@vger.kernel.org
Subject: Re: [FYI] lm3532: right registration to work with LED-backlight
Date: Tue, 17 Sep 2019 19:23:02 +0200 [thread overview]
Message-ID: <747f9567-e8c8-6816-7668-9eda4497cc54@gmail.com> (raw)
In-Reply-To: <20190917124210.GB27465@amd>
Hi Pavel,
On 9/17/19 2:42 PM, Pavel Machek wrote:
> Hi!
>
>>>>> +++ b/drivers/leds/leds-lm3532.c
>>>>> @@ -629,7 +629,7 @@ static int lm3532_parse_node(struct lm3532_data *priv)
>>>>>
>>>>> lm3532_init_registers(led);
>>>>>
>>>>> - ret = devm_led_classdev_register(priv->dev, &led->led_dev);
>>>>> + ret = devm_of_led_classdev_register(priv->dev, to_of_node(child), &led->led_dev);
>>>>
>>>> We no longer have devm_of_led_classdev_register(). You must use
>>>> devm_led_classdev_register_ext().
>>>
>>> Something like this (untested)?
>
>> If you want to properly switch to the new extended LED registration
>> API, then you need:
>>
>> .default_label = ":",
>> .devicename = led->client->name;
>>
>> and in addition to that you need to remove old way of composing
>> the LED name. Something like patch [0] for leds-lm3692x.c.
>> And also patch for DT for consistency would be needed (like [1]).
>>
>> However it will not change anything in LED naming in comparison
>> to the existing code, except that it will enable the possibility
>> of using 'function' and 'color' DT properties instead of deprecated
>> 'label'.
>>
>> I suppose that you expected some extra bonus by passing
>> DT node, but I'm not sure what exactly. Possibly you confused
>> this with the patch set [2] that allows for instantiating
>> backlight device on top of LED class device (it has been forgotten
>> btw and will miss 5.4).
>
> Yes, it is for LED backlight. Thanks for hints, you have corrected
> version in your inbox.
You need also below cleanups. Please compare my patches reworking
existing drivers in the for-next branch.
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
index 0507c6575c08..fc166f1a1789 100644
--- a/drivers/leds/leds-lm3532.c
+++ b/drivers/leds/leds-lm3532.c
@@ -9,7 +9,6 @@
#include <linux/types.h>
#include <linux/regulator/consumer.h>
#include <linux/module.h>
-#include <uapi/linux/uleds.h>
#include <linux/gpio/consumer.h>
#define LM3532_NAME "lm3532-led"
@@ -128,7 +127,6 @@ struct lm3532_als_data {
* @full_scale_current - The full-scale current setting for the current
sink.
* @led_strings - The LED strings supported in this array
* @enabled - Enabled status
- * @label - LED label
*/
struct lm3532_led {
struct led_classdev led_dev;
@@ -141,7 +139,6 @@ struct lm3532_led {
int full_scale_current;
int enabled:1;
u32 led_strings[LM3532_MAX_CONTROL_BANKS];
- char label[LED_MAX_NAME_SIZE];
};
/**
@@ -639,16 +636,7 @@ static int lm3532_parse_node(struct lm3532_data *priv)
fwnode_property_read_string(child, "linux,default-trigger",
&led->led_dev.default_trigger);
- ret = fwnode_property_read_string(child, "label", &name);
- if (ret)
- snprintf(led->label, sizeof(led->label),
- "%s::", priv->client->name);
- else
- snprintf(led->label, sizeof(led->label),
- "%s:%s", priv->client->name, name);
-
led->priv = priv;
- led->led_dev.name = led->label;
led->led_dev.brightness_set_blocking =
lm3532_brightness_set;
ret = devm_led_classdev_register(priv->dev, &led->led_dev);
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2019-09-17 17:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 21:52 [PATCH] leds: lm3532: Avoid potentially unpaired regulator calls Tony Lindgren
2019-08-28 8:42 ` Pavel Machek
2019-08-28 8:53 ` [FYI] lm3532: right registration to work with LED-backlight Pavel Machek
2019-08-28 20:32 ` Jacek Anaszewski
2019-09-08 8:03 ` Pavel Machek
2019-09-08 16:17 ` Jacek Anaszewski
2019-09-17 12:40 ` [PATCH] " Pavel Machek
2019-09-17 15:10 ` kbuild test robot
2019-09-17 12:42 ` [FYI] " Pavel Machek
2019-09-17 17:23 ` Jacek Anaszewski [this message]
2019-08-28 20:09 ` [PATCH] leds: lm3532: Avoid potentially unpaired regulator calls 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=747f9567-e8c8-6816-7668-9eda4497cc54@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=mpartap@gmx.net \
--cc=nekit1000@gmail.com \
--cc=pavel@ucw.cz \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
/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