From: David Gibson <david@gibson.dropbear.id.au>
To: Timur Tabi <timur@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: Could the DTS experts look at this?
Date: Wed, 13 Feb 2008 10:21:04 +1100 [thread overview]
Message-ID: <20080212232104.GC21230@localhost.localdomain> (raw)
In-Reply-To: <47B1BEE7.4050808@freescale.com>
On Tue, Feb 12, 2008 at 09:44:39AM -0600, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > On Tuesday 12 February 2008, David Gibson wrote:
> >> Or to expand. It's relatively easy now to just include multiple nodes
> >> in the tree and either delete or nop some of them out conditionally
> >> using libfdt.
>
> Yes, but what better place to store the conditions than in the
> device tree itself? How would libfdt know where the conditions are?
> Do you want to have two binary blobs?
libfdt wouldn't. The conditional logic must be in the agent using
libfdt.
> >> But the conditional logic should be in the manipulating
> >> agent (u-boot or bootwrapper or whatever), there's no way we're going
> >> to require a conditional expression parser to interpret the device
> >> tree blob itself.
>
> I think it's a great feature that solves a lot of problems, and it
> does so in an elegant and efficient manner. I look forward to
> trying to change your mind when I get around to implementing it.
>
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
>
> The problem with this is that if you use a version of libfdt that
> does not understand "linux,conditional-node", then your device tree
> will be wrong, because it could contain nodes that don't belong. We
> would need a new, incompatible version number for the device tree to
> make sure that this doesn't happen, even though nothing has changed
> in the binary layout of the tree.
Passing an incomplete device tree to an agent that doesn't expect it
is always going to cause trouble. This is nothing new. And as you've
said the interpretation of these variables in the conditionals is
already agent specific, so you'd still have to pass these
conditionalised trees to the correct agent in order for them to be
correctly interpreted.
No, this has to be agent-local logic. If you want to annotate your
agent's input device trees with information that will help it do this,
go for it, but don't expect it to be in any way a standardized aspect
of the device tree format.
--
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
next prev parent reply other threads:[~2008-02-12 23:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-08 23:30 Could the DTS experts look at this? Sean MacLennan
2008-02-10 5:47 ` Arnd Bergmann
2008-02-10 6:05 ` Sean MacLennan
2008-02-11 17:57 ` Timur Tabi
2008-02-11 23:54 ` David Gibson
2008-02-11 23:56 ` David Gibson
2008-02-12 0:21 ` Arnd Bergmann
2008-02-12 0:36 ` David Gibson
2008-02-12 18:51 ` Scott Wood
2008-02-12 23:17 ` David Gibson
2008-02-12 23:41 ` Timur Tabi
2008-02-12 23:50 ` David Gibson
2008-02-12 15:44 ` Timur Tabi
2008-02-12 18:58 ` Grant Likely
2008-02-12 19:08 ` Timur Tabi
2008-02-12 19:34 ` Grant Likely
2008-02-12 19:45 ` Timur Tabi
2008-02-12 20:43 ` Grant Likely
2008-02-12 23:35 ` David Gibson
2008-02-12 23:50 ` Timur Tabi
2008-02-13 0:10 ` Grant Likely
2008-02-12 23:26 ` David Gibson
2008-02-12 23:47 ` Timur Tabi
2008-02-13 0:08 ` David Gibson
2008-02-13 0:15 ` Grant Likely
2008-02-12 23:21 ` David Gibson [this message]
2008-02-11 0:14 ` David Gibson
2008-02-11 2:40 ` Sean MacLennan
2008-02-11 3:11 ` David Gibson
2008-02-11 3:49 ` Sean MacLennan
2008-02-11 23:59 ` David Gibson
2008-02-12 1:07 ` Sean MacLennan
2008-02-12 0:20 ` David Gibson
2008-02-12 0:41 ` Sean MacLennan
2008-02-12 0:48 ` David Gibson
2008-02-12 18:52 ` Scott Wood
2008-02-12 19:03 ` Grant Likely
2008-02-12 19:10 ` Scott Wood
2008-02-17 10:22 ` David Woodhouse
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=20080212232104.GC21230@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=timur@freescale.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).