From: David Gibson <david@gibson.dropbear.id.au>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Timur Tabi <timur@freescale.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: Could the DTS experts look at this?
Date: Wed, 13 Feb 2008 10:17:02 +1100 [thread overview]
Message-ID: <20080212231702.GB21230@localhost.localdomain> (raw)
In-Reply-To: <20080212185106.GA4042@loki.buserror.net>
On Tue, Feb 12, 2008 at 12:51:06PM -0600, Scott Wood wrote:
> On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
> > On Tue, Feb 12, 2008 at 01:21:44AM +0100, 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. 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.
> > >
> > > 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.
> > > In Sean's example, you can have linux,conditional-node="Rev.A" in
> > > some nodes and linux,conditional-node="Rev.B" in others, then
> > > knock out all devices that have a non-matching linux,conditional-node
> > > property, and finally remove the properties themselves before starting
> > > the kernel.
> >
> > Well, that's basically a u-boot issue. If they want to do their input
> > trees that way, and have helper functions that deal with it...
>
> The actual mechanism that we originially discussed, which Timur later
> morphed into conditions-on-nodes, was to have a separate hwoptions node,
> under which would be described various hwoptions (jumpers and such) whose
> state could be either detected by u-boot or set by environment variable.
> Each hwoption setting would contain a device tree fragment to be merged into
> the main device tree.
I'm not sure I'm entirely happy about storing the fragments under a
special node - but certainly u-boot could do that if it wants. What
would certainly be ok is to store various fragments as separate blobs
and fold them together as necessary. Which reminds me, I meant to
implement a "graft" function in libfdt.
--
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:17 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 [this message]
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
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=20080212231702.GB21230@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.