linux-kernel - Re: Should regulator core support parsing OF based fwnode?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191004155838.GE4866@sirena.co.uk>
Date:   Fri, 4 Oct 2019 16:58:38 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jean-Jacques Hiblot <jjhiblot@...com>
Cc:     mark.rutland@....com, daniel.thompson@...aro.org,
        Liam Girdwood <lgirdwood@...il.com>, tomi.valkeinen@...com,
        Sebastian Reichel <sebastian.reichel@...labora.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        robh+dt@...nel.org, Jacek Anaszewski <jacek.anaszewski@...il.com>,
        pavel@....cz, lee.jones@...aro.org, linux-leds@...r.kernel.org,
        dmurphy@...com
Subject: Re: Should regulator core support parsing OF based fwnode?

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)