From: Mark Brown <broonie@kernel.org>
To: Jean-Jacques Hiblot <jjhiblot@ti.com>
Cc: mark.rutland@arm.com, daniel.thompson@linaro.org,
Liam Girdwood <lgirdwood@gmail.com>,
tomi.valkeinen@ti.com,
Sebastian Reichel <sebastian.reichel@collabora.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, Jacek Anaszewski <jacek.anaszewski@gmail.com>,
pavel@ucw.cz, lee.jones@linaro.org, linux-leds@vger.kernel.org,
dmurphy@ti.com
Subject: Re: Should regulator core support parsing OF based fwnode?
Date: Fri, 4 Oct 2019 16:58:38 +0100 [thread overview]
Message-ID: <20191004155838.GE4866@sirena.co.uk> (raw)
In-Reply-To: <6df68ecb-f92e-fd9c-7f55-f66fa463263a@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
On Fri, Oct 04, 2019 at 05:13:13PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 16:40, Mark Brown wrote:
> > Why is the LED core populating anything? Is the LED core copying bits
> > out of the struct device for the actual device into a synthetic device
> > rather than passing the actual device in? That really doesn't seem like
> > a good idea, it's likely to lead to things like this where you don't
> > copy something that's required (or worse where something directly in the
> > struct device that can't be copied is needed).
> This is not a copy of a device of parent's of_node or something like that.
> You can think of a LED controller as a bus. It 'enumerates' its children
> LED, create the children devices (one per LED) and provides the functions to
> interact with them.
> The device node we are talking about here is a per-LED thing, it is a child
> node of the node of the LED controller.
> here is an example:
>
> tlc59108: tlc59116@40 { /* this is the node for the LED controller */
> status = "okay";
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "ti,tlc59108";
> reg = <0x40>;
>
> backlight_led: led@2 { /* this is the node of one LED attached to
> pin#2 of the LED controller */
> power-supply = <&bkl_fixed>;
> reg = <0x2>;
> };
Regulator supplies are supposed to be defined at the chip level rather
than subfunctions with names corresponding to the names on the chip.
This ensures that all chips look similar when you're mapping the
schematic into a DT, you shouldn't need to know about the binding for a
given chip to write a DT for it and if multiple people (perhaps working
on different OSs) write bindings for the same chip there should be a
good chance that they come up with the same mapping. The supply_alias
interface is there to allow mapping these through to subfunctions if
needed, it looks like the LED framework should be using this.
That said if you are doing the above and the LEDs are appearing as
devices it's extremely surprising that their of_node might not be
initialized.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-04 15:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 8:28 [PATCH v8 0/5] Add a generic driver for LED-based backlight Jean-Jacques Hiblot
2019-10-03 8:28 ` [PATCH v8 1/5] leds: populate the device's of_node when possible Jean-Jacques Hiblot
2019-10-04 21:08 ` Jacek Anaszewski
2019-10-03 8:28 ` [PATCH v8 2/5] leds: Add of_led_get() and led_put() Jean-Jacques Hiblot
2019-10-03 10:42 ` Sebastian Reichel
2019-10-03 12:47 ` Jean-Jacques Hiblot
2019-10-03 17:43 ` Jacek Anaszewski
2019-10-03 18:35 ` Mark Brown
2019-10-03 19:21 ` Jacek Anaszewski
2019-10-03 19:41 ` Mark Brown
2019-10-03 20:27 ` Should regulator core support parsing OF based fwnode? (was: Re: [PATCH v8 2/5] leds: Add of_led_get() and led_put()) Jacek Anaszewski
2019-10-04 10:12 ` Should regulator core support parsing OF based fwnode? Jean-Jacques Hiblot
2019-10-04 11:39 ` Should regulator core support parsing OF based fwnode? (was: Re: [PATCH v8 2/5] leds: Add of_led_get() and led_put()) Mark Brown
2019-10-04 13:33 ` Should regulator core support parsing OF based fwnode? Jean-Jacques Hiblot
2019-10-04 14:40 ` Mark Brown
2019-10-04 15:13 ` Jean-Jacques Hiblot
2019-10-04 15:58 ` Mark Brown [this message]
2019-10-04 16:12 ` Jean-Jacques Hiblot
2019-10-04 17:42 ` Mark Brown
2019-10-04 20:55 ` Jacek Anaszewski
2019-10-03 8:28 ` [PATCH v8 3/5] leds: Add managed API to get a LED from a device driver Jean-Jacques Hiblot
2019-10-03 10:47 ` Sebastian Reichel
2019-10-03 8:28 ` [PATCH v8 4/5] dt-bindings: backlight: Add led-backlight binding Jean-Jacques Hiblot
2019-10-03 11:17 ` Sebastian Reichel
2019-10-03 8:28 ` [PATCH v8 5/5] backlight: add led-backlight driver Jean-Jacques Hiblot
2019-10-03 11:47 ` Sebastian Reichel
2019-10-03 17:23 ` Jean-Jacques Hiblot
2019-10-03 11:40 ` [PATCH v8 0/5] Add a generic driver for LED-based backlight Lee Jones
2019-10-08 19:55 ` 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=20191004155838.GE4866@sirena.co.uk \
--to=broonie@kernel.org \
--cc=daniel.thompson@linaro.org \
--cc=dmurphy@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.anaszewski@gmail.com \
--cc=jjhiblot@ti.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=tomi.valkeinen@ti.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
all inboxes | Powered by JetHome®