lkml.org 
[lkml]   [2012]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
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.

g.


\
 
 \ /
  Last update: 2012-11-09 22:21    [W:0.732 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site