All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Dahl <ada@thorsis.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Alexander Dahl <post@lespocky.de>,
	linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
	Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-kernel@vger.kernel.org,
	Peter Ujfalusi <peter.ujfalusi@ti.com>
Subject: Re: [PATCH v4 1/3] leds: Require valid fwnode pointer for composing name
Date: Tue, 15 Sep 2020 11:14:49 +0200	[thread overview]
Message-ID: <2642665.8NmDdnWKvZ@ada> (raw)
In-Reply-To: <6652b897-5044-713b-6f06-83d07be0dba7@gmail.com>

Hello Jacek,

thanks for your feedback. See below.

Am Freitag, 11. September 2020, 23:26:43 CEST schrieb Jacek Anaszewski:
> On 9/11/20 5:40 PM, Alexander Dahl wrote:
> > The function 'led_compose_name()' is called in
> > 'led_classdev_register_ext(()' only and in its implementation it always
> > parses the fwnode passed with the init_data struct.  If there's no
> > fwnode, EINVAL is returned and 'led_classdev_register_ext()' returns
> > early.
> > 
> > If this is detected early the same fallback mechanism can be used , as
> > if init_data itself is NULL.  This will allow drivers to pass fully
> > populated 'init_data' or sparse initialized 'init_data' with a NULL
> > fwnode in a more elegant way with only one function call.
> > 
> > Fixes: bb4e9af0348d ("leds: core: Add support for composing LED class
> > device names") Suggested-by: Pavel Machek <pavel@ucw.cz>
> > Signed-off-by: Alexander Dahl <post@lespocky.de>
> > ---
> > 
> > Notes:
> >      v4:
> >        * added this patch to series (Suggested-by: Pavel Machek)
> >   
> >   drivers/leds/led-class.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> > index cc3929f858b6..3da50c7ecfe7 100644
> > --- a/drivers/leds/led-class.c
> > +++ b/drivers/leds/led-class.c
> > @@ -346,7 +346,7 @@ int led_classdev_register_ext(struct device *parent,
> > 
> >   	const char *proposed_name = composed_name;
> >   	int ret;
> > 
> > -	if (init_data) {
> > +	if (init_data && init_data->fwnode) {
> 
> This does not cover the case when we don't have fwnode but we
> have init_data->default_label that led_compose_name() can make use of.
> 
> >   		if (init_data->devname_mandatory && !init_data->devicename) {
> >   		
> >   			dev_err(parent, "Mandatory device name is missing");
> >   			return -EINVAL;

You're right, I missed that part in that if/else if construct in 
led_compose_name() … I looked at the code for some more time now and could not 
come up with an elegant change to the led-core or led-class. :-/

However I also had another look at leds-pwm and for me it seems that it is 
used by fwnode (DT, ACPI, ??) based devices only.  I could not find a single 
user of leds-pwm as a platform driver, which is probably why 141f15c66d94 
("leds: pwm: remove header") was possible?

I had a look at the history of the leds-pwm driver and when introduced in 2009 
platform based board files where a thing, no dt, of, or fwnode yet, at least 
for arm, right?  Device tree support for leds-pwm was added in 2012 by Peter 
Ujfalusi.

So if those code paths in leds-pwm are not used anymore, what about dropping 
that platform support in leds-pwm driver?  That would mean we always have 
fwnode non-null and would not require a change in led-class at all?

Greets
Alex




  reply	other threads:[~2020-09-15  9:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 15:40 [PATCH v4 0/3] leds: pwm: Make automatic labels work Alexander Dahl
2020-09-11 15:40 ` [PATCH v4 1/3] leds: Require valid fwnode pointer for composing name Alexander Dahl
2020-09-11 21:26   ` Jacek Anaszewski
2020-09-15  9:14     ` Alexander Dahl [this message]
2020-09-15 21:14       ` Jacek Anaszewski
2020-09-11 15:40 ` [PATCH v4 2/3] leds: pwm: Allow automatic labels for DT based devices Alexander Dahl
2020-09-11 15:40 ` [PATCH v4 3/3] dt-bindings: leds: Convert pwm to yaml Alexander Dahl
2020-09-15 20:37   ` Rob Herring
2020-09-18 15:03     ` Alexander Dahl
2020-09-18 15:35       ` Rob Herring

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=2642665.8NmDdnWKvZ@ada \
    --to=ada@thorsis.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=peter.ujfalusi@ti.com \
    --cc=post@lespocky.de \
    --cc=robh+dt@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.