From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: Should regulator core support parsing OF based fwnode? Date: Fri, 4 Oct 2019 16:58:38 +0100 Message-ID: <20191004155838.GE4866@sirena.co.uk> References: <62591735-9082-1fd7-d791-07929ddaa223@gmail.com> <20191003183554.GA37096@sirena.co.uk> <25b9614f-d6be-9da5-0fe5-eb58c8c93850@gmail.com> <20191003194140.GE6090@sirena.co.uk> <20191004113942.GB4866@sirena.co.uk> <20191004144029.GC4866@sirena.co.uk> <6df68ecb-f92e-fd9c-7f55-f66fa463263a@ti.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Return-path: Content-Disposition: inline In-Reply-To: <6df68ecb-f92e-fd9c-7f55-f66fa463263a@ti.com> Sender: linux-kernel-owner@vger.kernel.org To: Jean-Jacques Hiblot Cc: mark.rutland@arm.com, daniel.thompson@linaro.org, Liam Girdwood , tomi.valkeinen@ti.com, Sebastian Reichel , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Jacek Anaszewski , pavel@ucw.cz, lee.jones@linaro.org, linux-leds@vger.kernel.org, dmurphy@ti.com List-Id: dri-devel@lists.freedesktop.org --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 chi= ld > node of the node of the LED controller. > here is an example: >=20 > =A0=A0=A0 tlc59108: tlc59116@40 { /* this is the node for the LED control= ler */ > =A0=A0=A0 =A0=A0=A0 status =3D "okay"; > =A0=A0=A0 =A0=A0=A0 #address-cells =3D <1>; > =A0=A0=A0 =A0=A0=A0 #size-cells =3D <0>; > =A0=A0=A0 =A0=A0=A0 compatible =3D "ti,tlc59108"; > =A0=A0=A0 =A0=A0=A0 reg =3D <0x40>; >=20 > =A0=A0=A0 =A0=A0=A0 backlight_led: led@2 { /* this is the node of one LED= attached to > pin#2 of the LED controller */ > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 power-supply =3D <&bkl_fixed>; > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 reg =3D <0x2>; > =A0=A0=A0 =A0=A0=A0 }; 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. --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl2XbC0ACgkQJNaLcl1U h9CmMwf9ECgZ2ghDJUYkumszQL7edht7aQckB9pgZYkckEmwTq38eVilMfRXG/tJ mRbJ2jFnduiEXOXn5qNm+bj918hFDgfAPdAVOx6ZFCz79rtrR6eqNK7lZoVnalln tt62hjS3w74fYHKokbcd6s59q0dV1oVSVwxLx6ZENzkhZOA8mgp+xx43Tx2NrQVN rO+XtTKTMsAnvEYJZYT2K9PkvPCNb6358cr/etapbLTHEje7priUojy2vRwoh1CA Gwm5fir1Sxr3DL9MKQZ+Z9DMPWEQWURu+Ewslbhcb0jxKzPIP9vcJTKrlRW8JBhl 94yp9Hat1NShg+SsPvwQ3ROQmDssTQ== =BPJg -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt--