Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"info@metux.net" <info@metux.net>
Cc: "dmurphy@ti.com" <dmurphy@ti.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"pavel@ucw.cz" <pavel@ucw.cz>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [RFC PATCH 0/5] leds: Add DT node finding and parsing to core
Date: Mon, 18 Nov 2019 10:38:16 +0000
Message-ID: <946f091e79242b9e71d5ce8ad12c899feefa22cd.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <ed000cda-3138-3172-1b4c-586b5bfd8d72@metux.net>

Hello Enrico & All,

First of all - thanks for showing the interest :] I am happy knowing
someone actually was interested about the RFC :)

On Mon, 2019-11-18 at 10:21 +0100, Enrico Weigelt, metux IT consult
wrote:
> Hi,
> 
> 
> > The thing is that
> > this approach requires the LED controller binding to dictate
> > allowed
> > LED node names - which may or may not be doable. I need your help
> > to
> > evaluate this and suggest better options :)
> 
> even though I like the idea of convention-over-code, but if that's
> changing allowed LED names that would risk breaking things, eg:
> 
> a) existing DT's (in the field) become incompatible with newer
>    kernel versions

This was my main concern. This of course would not mean that we could
not take this approach for new LED controller drivers - but that would
(probably) lead to dual led registration interface - one for current
approach where LED drivers do all the dirty work themself - and parse
the DT - one for new drivers which could leave DT parsing to LED core.

> b) existing userlands that rely on speicific LED names become
>    incomatible with newer kernel versions.

I didn't even think this far, but yes, I see... LED node name might be
reflected in user-space LED name. I won't start arguing if this is sane
or not - this is what we seem to be living with today :)

Anyways, I did send out a LED core change patch which allows one to add
either the node-name, or a property-value pair in init_data. LED core
can then use either of these to do LED node lookup. If none of these is
given, then we can fall-back to existing logic. That way we won't
change existing stuff.
Here:
https://lore.kernel.org/lkml/258b5c9934e2b31a5f433a7dbb908dfe5da3d30c.1574059625.git.matti.vaittinen@fi.rohmeurope.com/T/#u


I didn't invest too much of time on this yet - but at first glimpse it
seemed that at least some of the drivers did use reg - property with
fixed value to do the matching. Those could set the property name to
'reg' and value to 'X' and leave the DT node lookup and common property
parsing to the LED core. If my patch won't get too big objection (and
if no fatal flaws are found from the idea) - then I might try and find
the time to do some follow-up patches simplifying existing LED
drivers...

> 
> 
> 
> --mtx
> 


  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 12:46 Matti Vaittinen
2019-10-29 12:46 ` [RFC PATCH 1/5] leds: Add common LED binding parsing support to LED class/core Matti Vaittinen
2019-10-29 12:47 ` [RFC PATCH 2/5] dt-bindings: an30259a: example for using fixed LED node names Matti Vaittinen
2019-11-06  3:42   ` Rob Herring
2019-11-06 11:30     ` SPAM (R/EU IT) // " Vaittinen, Matti
2019-10-29 12:47 ` [RFC PATCH 3/5] leds: an30259a: Offload DT node locating and parsing to core Matti Vaittinen
2019-10-29 12:48 ` [RFC PATCH 4/5] dt-bindings: lm3692x: example for using fixed LED node names Matti Vaittinen
2019-10-29 12:48 ` [RFC PATCH 5/5] leds: lm3692x: Offload DT node locating and parsing to core Matti Vaittinen
2019-11-18  9:21 ` [RFC PATCH 0/5] leds: Add DT node finding " Enrico Weigelt, metux IT consult
2019-11-18 10:38   ` Vaittinen, Matti [this message]
2019-11-19 19:52     ` Enrico Weigelt, metux IT consult
2019-11-20  7:37       ` Vaittinen, Matti

Reply instructions:

You may reply publically 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=946f091e79242b9e71d5ce8ad12c899feefa22cd.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=info@metux.net \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mazziesaccount@gmail.com \
    --cc=pavel@ucw.cz \
    --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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git