Re: Could the DTS experts look at this?

[Timur Tabi <timur@freescale.com>]

Grant Likely wrote:

> Then use a local version in the data; don't overload the purpose of
> the dtb version.

I don't know what you mean by that.

> I don't think it is yet possible to define a reasonable 'standard
> manner' for massaging device trees.  There are going to be a lot of
> experiments and false starts before we come to consensus on common
> manipulations which everyone will want to have access too.  Therefore
> for the time being dtb fixups and manipulations will remain a board
> specific thing.

That's okay with me.  I'm just proposing one method that I like, and Scott 
proposed another.

> And when something comes along that doesn't fit into that model?  Add
> more constructs?

If necessary, yes.  What's wrong with expanding the power of the device tree 
format when it solves more problems?

>  I say better to handle that within the existing data
> format.

And the point I've been trying to make is that we have real problems today that 
cannot be solved elegantly with the current device tree problem.  Having 
board-specific code in U-Boot that is hard-coded to look for specific nodes in 
the device tree, and making hard-coded edits on that tree, is *not* elegant.

>  If we get it wrong, then we just change the affected device
> trees and boot loaders.  We don't have to upgrade every platform that
> uses dt blobs.

Only the platforms that need to take advantage of conditional nodes need to be 
upgraded in the first place.  Most platforms are happy with just one device tree.

>> That's okay too, except that if we just add additional nodes that describe
>> conditions, then we need to make sure that whatever parses that DTB must also
>> parse those additional nodes.  The only way to do that is create a new version
>> number, like 18, which is marked as being incompatible with the current version
>> (17).  Otherwise, a person could pass that DTB to an old version of U-Boot, and
>> U-boot will just pass it on to the kernel as-is.
> 
> That's not a dtb version issue.  That is a dtb content issue. 

Technically, that's true, but ...

> It does
> not warrant changing the dtb version number.

Then how do you solve the problem of passing a device tree to a boot loader that 
does not know how to parse it properly?  A device tree with these additional 
nodes *must* be parsed by a boot loader that is aware of them.  Otherwise, it 
will pass the device tree as-is to the kernel without warning.  This is a bad 
thing, and steps should be taken to prevent that.  If you can think of a way to 
make this happen without changing the version number, I'd love to hear.  All I'm 
hearing from you now is denial that this is a problem.

>>> We've already got that issue.  If you pass the device tree for the
>>> wrong board it will still validate correctly, but the board is not
>>> going to boot.
>> There's nothing stopping U-Boot today from scanning the device tree and making
>> sure the SOC's compatible node is correct.  That's not currently done, but it
>> could be.
> 
> Fair enough, and it is also reasonable for the boot loader to look for
> a specific property name to decide how to massage the data structure.
> This alone does not require a dtb version change.

Current versions of U-Boot do not know how to do this.  So again, I'm asking 
you: how do you solve the problem of passing a device tree with additional nodes 
to a boot loader that does not know how to parse them properly?  How do you 
prevent that old U-Boot from ignoring those nodes?

> I'm not missing the point because I disagree entirely with the
> addition of conditional expressions to the device tree.  Instead, I
> think properties can be added to the device tree that a bootloader can
> look for and decide to apply conditions against them which means the
> conditions are encoded in the boot loader, not the device tree.  (the
> device tree simply contains data which supports the boot loaders
> decision; a rather different thing).

Then why bother passing a DTB to the boot loader at all?  Why not just have the 
boot loader create the device tree from scratch?


-- 
Timur Tabi
Linux kernel developer at Freescale