From: Daniel Mack <zonque@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Merging device trees at runtime for module-based systems
Date: Fri, 26 Oct 2012 09:24:11 +0200 [thread overview]
Message-ID: <508A3A9B.50804@gmail.com> (raw)
In-Reply-To: <20121026005319.GI7222@truffula.fritz.box>
On 26.10.2012 02:53, David Gibson wrote:
> On Thu, Oct 25, 2012 at 10:46:32PM +0200, Wolfgang Denk wrote:
>> Dear Daniel,
>>
>> In message <50893633.6070408@gmail.com> you wrote:
>>>
>>> Overwrites must be addressed in the first place. The most common example
>>> is that a more generic part (the module tree) registers all details
>>> about a peripheral up-front but then sets its status to 'disabled'. That
>>> way, the more specific part (the base board tree) can overwrite this
>>> property to 'okay' at wish to enable it and not care for the pre-defined
>>> details. This is also how we do things in our device-trees.
>>
>> Agreed.
>>
>>>> I definitely can see the benefit of such a feature and would be happy
>>>> if you could go forward and implement it.
>>>
>>> Ok then. I guess this should be something that can eventually be merged
>>> back into libfdt?
>>
>> I can't speak for the FDT custodian, but I think this makes a lot of
>> sense.
>
> As a rule I'm happy to see more functionality for libfdt. I've only
> seen bits and pieces of this thread, though, so I'd need to see a
> summary of what exactly is being proposed.
That's strange, as I copied you from the very first posting. Anyway,
here's the archive:
http://lists.denx.de/pipermail/u-boot/2012-October/138227.html
I would especially like to know where such a new functionality should
live, which data types it should operate on and what would be an
appropriate name for it.
Many thanks,
Daniel
next prev parent reply other threads:[~2012-10-26 7:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 9:47 [U-Boot] Merging device trees at runtime for module-based systems Daniel Mack
2012-10-25 12:44 ` Wolfgang Denk
2012-10-25 12:53 ` Daniel Mack
2012-10-25 20:46 ` Wolfgang Denk
2012-10-26 0:53 ` David Gibson
2012-10-26 7:24 ` Daniel Mack [this message]
2012-10-26 18:21 ` Simon Glass
2012-11-01 3:26 ` David Gibson
2012-11-01 9:24 ` Daniel Mack
2012-11-03 15:25 ` David Gibson
2012-11-03 15:35 ` Daniel Mack
2012-10-26 18:39 ` Stephen Warren
2012-10-26 20:06 ` Wolfgang Denk
2012-10-31 23:00 ` Daniel Mack
2012-10-31 23:00 ` [U-Boot] " Daniel Mack
2012-10-31 23:13 ` Stephen Warren
2012-10-31 23:13 ` [U-Boot] " Stephen Warren
2012-10-31 23:21 ` Daniel Mack
2012-10-31 23:21 ` [U-Boot] " Daniel Mack
[not found] ` <5091AD78.3060701-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-31 23:56 ` Mitch Bradley
2012-10-31 23:56 ` Mitch Bradley
2012-11-01 4:36 ` Stephen Warren
2012-11-01 4:36 ` [U-Boot] " Stephen Warren
[not found] ` <5091FC38.2020806-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-01 5:02 ` Mitch Bradley
2012-11-01 5:02 ` Mitch Bradley
2012-11-02 4:53 ` David Gibson
2012-11-02 4:53 ` David Gibson
2012-11-06 23:05 ` Grant Likely
2012-11-06 23:05 ` Grant Likely
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=508A3A9B.50804@gmail.com \
--to=zonque@gmail.com \
--cc=u-boot@lists.denx.de \
/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.