Hi David,
(Adding Pantelis and Tom, since I'm going somewhat off-topic from
the original thread, and they are impacted by what I am asking.)
On 07/15/17 22:35, David Gibson wrote:
> On Thu, Jul 13, 2017 at 09:47:01AM -0700, Florian Fainelli wrote:
>> On 07/12/2017 09:23 PM, Cyril Novikov wrote:
>>> On 7/12/2017 10:10 AM, Florian Fainelli wrote:
>>>> On 07/11/2017 11:15 PM, Cyril Novikov wrote:
>>>>> Hi, all!
>>>>>
< snip >
> The
> phandle fixup information goes into the special __local_fixups__ and
> __fixups__ nodes (which have gratuitiously different format, but
> that's a rant for elsewhere).
< snip >
And in another email, David describes the __local_fixups__ format
nicely, so I'll just copy that here instead of re-inventing it:
> Well, I don't want to invent a new encoding if we can possibly avoid
> it. The current encoding used for overlay generation looks like this
>
> / {
> target: node@0 {
> };
> node@1 {
> ref = <&target>;
> };
> __local_fixups__ = {
> node@1 {
> ref = <0>;
> };
> };
> };
>
> Basically, __local_fixups__ has a subtree which paralells the main
> tree. Each property found under __local_fixups__ is a list of offsets
> at which phandle references appear in the corresponding property in
> the main tree.
I share your desire to rant about the different formats between
__local_fixups__ and __fixups__. But I have not come up with an
alternate format for __local_fixups__ that makes me happy. The
best format that I have come up with so far would be:
/ {
target: node@0 {
};
node@1 {
ref = <&target>;
ref2 = <&target 42 &target_2>;
};
target_2: node@2 {
};
__local_fixups__ = {
x1 = <"node@1/ref" 0>;
x2 = <"node@1/ref2" 0 8>;
};
};
};
x1 and x2 are abitrary property names.
The format of each __local_fixups__ property is
- path of property referencing a phandle
- list of offsets of the phandle in the property
As another alternative, Grant was thinking about adding
a new block to the FDT format to contain the phandle
information. That would remove the need to come up
with a convoluted dts syntax, but adds in the problem
of bootloaders corrupting the new block if they were
not aware of it. He had thoughts about versioning
and checksums to detect the corruption it if did
occur.
If we were starting from scratch, do you have any other
approach that might be fruitful? It seems like maybe
I am missing something that requires thinking outside
the box.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
