linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>,
	Rob Herring <robherring2@gmail.com>,
	Deepak Saxena <dsaxena@linaro.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Scott Wood <scottwood@freescale.com>,
	Tony Lindgren <tony@atomide.com>, Kevin Hilman <khilman@ti.com>,
	Matt Porter <mporter@ti.com>,
	Koen Kooi <koen@dominion.thruhere.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Felipe Balbi <balbi@ti.com>, Russ Dill <Russ.Dill@ti.com>,
	linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Date: Tue, 13 Nov 2012 11:05:15 +1100	[thread overview]
Message-ID: <20121113000515.GP4696@truffula.fritz.box> (raw)
In-Reply-To: <CACxGe6v7q2=Dxn6BE_V-w9CEKxAsZ6zQd5Uqm4TeYGYCCu76cg@mail.gmail.com>

On Fri, Nov 09, 2012 at 09:08:14PM +0000, Grant Likely wrote:
> On Fri, Nov 9, 2012 at 2:26 AM, David Gibson
> <david@gibson.dropbear.id.au> wrote:
> >> Summary points:
> >> - Create an FDT overlay data format and usage model
> >>   - SHALL reliable resolve or validate of phandles between base and
> >>     overlay trees
> >
> > So, I'm not at all clear on what this proposed phandle validation
> > would involve.  I'm also not convinced it's as necessary as you
> > think, more on that below.
> 
> Simply this: I'm taking this example from the omap3-beagle-xm.dts. It
> has the following stanza which is currently rolled into the resulting
> .dtb when compiled.
> 
> &i2c1 {
>         clock-frequency = <2600000>;
> 
>         twl: twl@48 {
>                 reg = <0x48>;
>                 interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>                 interrupt-parent = <&intc>;
> 
>                 vsim: regulator-vsim {
>                         compatible = "ti,twl4030-vsim";
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <3000000>;
>                 };
> 
>                 twl_audio: audio {
>                         compatible = "ti,twl4030-audio";
>                         codec {
>                         };
>                 };
>         };
> };
> 
> However, if it were compiled into a separate dtb overlay it might look
> like this:
> 
> / {
>     .readonly;
>     ocp {
>         .readonly;
>         interrupt-controller@48200000 {
>             phandle = <0x1234>; /* EXPECTED PHANDLE */
>             .readonly;
>         };
>         i2c@48070000 {
>             .must-exist;
>             clock-frequency = <2600000>;
> 
>             twl@48 {
>                 reg = <0x48>;
>                 interrupts = <7>;
>                 interrupt-parent = <0x1234>;   /* RESOLVED PHANDLE */
> 
>                 vsim: regulator-vsim {
>                         compatible = "ti,twl4030-vsim";
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <3000000>;
>                 };
> 
>                 twl_audio: audio {
>                         compatible = "ti,twl4030-audio";
>                         codec {
>                         };
>                 };
>             };
>         };
>     };
> };
> 
> Notice I've included the intc node and it's phandle. By phandle
> validation I merely mean that when applying an overly the firmware or
> kernel must verify that the phandles in the overlay match the phandle
> in the base tree. If they don't match, then refuse to apply the
> overhead. This approach avoids the need to find and fixup phandles in
> the overlay. And if the phandle is generated from a hash of the
> full_name, then the resulting phandle will only change if the node
> moves.
> 
> Similarly, at application time it should be verified that the nodes
> with a .readonly or .must-exist property could be verified to actually
> exist before attempting to apply the overlay. I used two different
> properties with the idea that only certain nodes would need to be
> modified... exactly what the policies should be is yet to be
> determined.

Ok, I see.  I really don't like it much, but I understand.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  reply	other threads:[~2012-11-13  0:30 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 20:40 [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Grant Likely
2012-11-05 21:40 ` Tabi Timur-B04825
2012-11-05 23:22   ` Tony Lindgren
2012-11-09 12:06     ` Grant Likely
2012-11-06  0:07   ` Grant Likely
2012-11-06 10:31   ` Pantelis Antoniou
2012-11-07 22:35   ` Ryan Mallon
2012-11-08 13:28     ` Koen Kooi
2012-11-08 14:09       ` Timur Tabi
2012-11-08 17:00       ` Mitch Bradley
2012-11-06 10:30 ` Pantelis Antoniou
2012-11-06 11:14   ` Grant Likely
2012-11-06 18:35     ` Tony Lindgren
2012-11-06 19:29       ` Russ Dill
2012-11-06 19:41         ` Pantelis Antoniou
2012-11-06 22:17           ` Stephen Warren
2012-11-06 19:34     ` Pantelis Antoniou
2012-11-06 20:45       ` Grant Likely
2012-11-06 20:50         ` Grant Likely
2012-11-07  8:06         ` Pantelis Antoniou
2012-11-07 15:33           ` Alan Tull
2012-11-09 17:03           ` Grant Likely
2012-11-07  8:13         ` Pantelis Antoniou
2012-11-07 10:19           ` Benoit Cousson
2012-11-07 11:02             ` Pantelis Antoniou
2012-11-07 11:12               ` Benoit Cousson
2012-11-07 11:23                 ` Pantelis Antoniou
2012-11-09 20:33               ` Grant Likely
2012-11-12 11:34                 ` Pantelis Antoniou
2012-11-12 13:01                   ` Grant Likely
2012-11-07 17:25             ` Stephen Warren
2012-11-07 22:10               ` Pantelis Antoniou
2012-11-08 10:36               ` Cousson, Benoit
2012-11-09  5:32   ` Joel A Fernandes
2012-11-09 14:29     ` David Gibson
2012-11-10  3:15       ` Joel A Fernandes
2012-11-09 21:22     ` Grant Likely
2012-11-12 11:47       ` Pantelis Antoniou
2012-11-13  3:59       ` Joel A Fernandes
2012-11-09 22:59     ` Stephen Warren
     [not found]   ` <-4237940489086529028@unknownmsgid>
     [not found]     ` <559B8433-67C3-4A1A-A5D6-859907655176@antoniou-consulting.com>
2012-11-10  3:36       ` Joel A Fernandes
2012-11-12 12:48         ` Pantelis Antoniou
2012-11-13  2:28         ` David Gibson
2012-11-06 22:37 ` Stephen Warren
2012-11-07  0:54   ` Mitch Bradley
2012-11-09 17:02     ` Grant Likely
2012-11-12 11:29       ` Pantelis Antoniou
2012-11-07  8:47   ` Pantelis Antoniou
2012-11-07 17:18     ` Stephen Warren
2012-11-07 22:08       ` Pantelis Antoniou
2012-11-09 16:28   ` Grant Likely
2012-11-09 23:23     ` Stephen Warren
2012-11-09 23:40       ` Grant Likely
2012-11-12 10:53         ` Koen Kooi
2012-11-12 12:10       ` Pantelis Antoniou
2012-11-12 16:52         ` Stephen Warren
2012-11-13  7:25           ` David Gibson
2012-11-13  8:09             ` Pantelis Antoniou
2012-11-13 12:24               ` Grant Likely
2012-11-13 13:38                 ` Pantelis Antoniou
2012-11-15  4:57                   ` David Gibson
2012-11-13 17:10               ` Stephen Warren
2012-11-13 23:30               ` David Gibson
2012-11-14  0:00                 ` Pantelis Antoniou
2012-11-13 16:57             ` Stephen Warren
2012-11-13 18:10               ` Mitch Bradley
2012-11-13 18:29                 ` Stephen Warren
2012-11-13 19:09                   ` Mitch Bradley
2012-11-13 19:11                     ` Pantelis Antoniou
2012-11-17 22:27       ` Jean-Christophe PLAGNIOL-VILLARD
2012-11-20 17:09         ` Grant Likely
2012-11-11 20:47     ` Rob Landley
2012-11-12 12:50       ` Pantelis Antoniou
2012-11-12 16:54         ` Stephen Warren
2012-11-12 11:23     ` Pantelis Antoniou
2012-11-12 16:49       ` Stephen Warren
2012-11-12 17:00         ` Pantelis Antoniou
2012-11-12 17:10           ` Stephen Warren
2012-11-12 17:19             ` Pantelis Antoniou
2012-11-12 17:29               ` Stephen Warren
2012-11-12 17:38                 ` Pantelis Antoniou
2012-11-12 20:16       ` Russ Dill
2012-11-12 16:45     ` Stephen Warren
2012-11-09  2:26 ` David Gibson
2012-11-09 15:40   ` Pantelis Antoniou
2012-11-13  0:03     ` David Gibson
2012-11-09 21:08   ` Grant Likely
2012-11-13  0:05     ` David Gibson [this message]
2012-11-09 21:42   ` Grant Likely
2012-11-13  1:05     ` David Gibson
2012-11-13  5:22       ` Stephen Warren
2012-11-13  6:54         ` David Gibson
2012-11-09 22:57   ` Stephen Warren
2012-11-09 23:27     ` Grant Likely
2012-11-12 12:05     ` Pantelis Antoniou
2012-11-09 23:14   ` Stephen Warren
2012-11-09 23:06 ` Stephen Warren
2012-11-09 23:32   ` Grant Likely
2012-11-12 11:03 ` Koen Kooi

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=20121113000515.GP4696@truffula.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=Russ.Dill@ti.com \
    --cc=balbi@ti.com \
    --cc=benh@kernel.crashing.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dsaxena@linaro.org \
    --cc=grant.likely@secretlab.ca \
    --cc=khilman@ti.com \
    --cc=koen@dominion.thruhere.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mporter@ti.com \
    --cc=panto@antoniou-consulting.com \
    --cc=robherring2@gmail.com \
    --cc=scottwood@freescale.com \
    --cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).