All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <info@metux.net>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>,
	"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>
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: Tue, 19 Nov 2019 20:52:04 +0100	[thread overview]
Message-ID: <56d3a81e-f675-fd5e-06a7-8039bf02468e@metux.net> (raw)
In-Reply-To: <946f091e79242b9e71d5ce8ad12c899feefa22cd.camel@fi.rohmeurope.com>

On 18.11.19 11:38, Vaittinen, Matti wrote:

Hi,

>> 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 

Maybe just a flag for that ? Perhaps the driver could also specify a
list of node names for the LEDs, so led-core can do the lookup for them.

>> 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 :)

Especially in embedded world, this can really make sense: applications
just use a defined LED name, no matter which board it's running on.
Convention over configuration.

Personally, I also like to use LED subsystem as frontend for things like
gpio-driven relais, etc, and assign semantically fitting names instead
of "technical" ones,

> 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...

Sounds good :)


--mtx

-- 
Dringender Hinweis: aufgrund existenzieller Bedrohung durch "Emotet"
sollten Sie *niemals* MS-Office-Dokumente via E-Mail annehmen/öffenen,
selbst wenn diese von vermeintlich vertrauenswürdigen Absendern zu
stammen scheinen. Andernfalls droht Totalschaden.
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  reply	other threads:[~2019-11-19 19:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 12:46 [RFC PATCH 0/5] leds: Add DT node finding and parsing to core 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
2019-11-19 19:52     ` Enrico Weigelt, metux IT consult [this message]
2019-11-20  7:37       ` Vaittinen, Matti
2020-02-09 22:46       ` Pavel Machek

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=56d3a81e-f675-fd5e-06a7-8039bf02468e@metux.net \
    --to=info@metux.net \
    --cc=Matti.Vaittinen@fi.rohmeurope.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=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
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.