From: Timur Tabi <timur@freescale.com>
To: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Zhang Wei-r63237 <Wei.Zhang@freescale.com>
Subject: Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
Date: Fri, 18 May 2007 12:39:19 -0500 [thread overview]
Message-ID: <464DE4C7.7030906@freescale.com> (raw)
In-Reply-To: <464DE2D3.3090805@smiths-aerospace.com>
Jerry Van Baren wrote:
>> I'd like to point out that what I originally proposed was much simpler
>> than this;
Actually, we're talking about the same thing, but I guess my over-simplification back-fired.
> Aye, that looks useful and reasonable to me. In one of my previous
> spiels I talked about merging fragments of fdt blobs. That was a
> half-baked thought, the above dts (blob) would have all the fragments in
> it and the u-boot board-specific logic would be copying/moving the
> selected nodes. That has a lot of benefits...
The idea stemmed from a desire to have a single DTS file for a given board, even in
situations where jumpers changed what hardware was enabled.
> * The above should result in reasonable board-specific code.
> * We may want to invent a libfdt move/copy subtree function (I don't
> recall one being in there). Board specific code would want to
> move selected subtrees out of /u-boot,hwoptions into the
> appropriate final node. All the pieces are in libfdt, just would
> need to be hooked together in a utility subroutine.
Just being able to delete a given node/property would be enough. By default, the nodes
with conditionals would be present in the device tree. The boot loader would then also
strip out all conditionals from the device tree before passing it to the kernel. The
kernel would then receive a standard device tree like it does today.
> * With the above, nothing in the infrastructure (dtc, libfdt) needs to
> change.
>
> On a related note, would it be better to name the node
> "/u-boot/hwoptions" (two levels deep)? It seems very desirable to me to
It's not a u-boot-specific concept. The idea of representing jumpers (and other hardware
options) in the device tree is not something that's unique to u-boot or any boot loader.
The conditionals, however, are a bootloader-specific concept. We don't want Linux to see
them.
--
Timur Tabi
Linux Kernel Developer @ Freescale
next prev parent reply other threads:[~2007-05-18 17:39 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 16:17 [PATCH 0/5] MPC8641 HPCN fixes Wade Farnsworth
2007-05-15 16:23 ` [PATCH 1/5] Add MTD support to mpc8641_hpcn.dts Wade Farnsworth
2007-05-15 16:27 ` [PATCH 2/5] Add legacy devices " Wade Farnsworth
2007-05-16 16:37 ` Jon Loeliger
2007-05-16 17:59 ` Wade Farnsworth
2007-05-16 19:59 ` Segher Boessenkool
2007-05-16 19:55 ` Segher Boessenkool
2007-05-16 20:03 ` Sergei Shtylyov
2007-05-16 20:17 ` Wade Farnsworth
2007-05-16 23:40 ` Segher Boessenkool
2007-05-16 23:47 ` Segher Boessenkool
2007-05-17 0:11 ` Wade Farnsworth
2007-05-17 0:09 ` Wade Farnsworth
2007-05-18 16:44 ` Jon Loeliger
2007-05-21 16:04 ` Wade Farnsworth
2007-05-21 16:10 ` Jon Loeliger
2007-05-21 16:51 ` Wade Farnsworth
2007-05-16 20:29 ` Wade Farnsworth
2007-07-07 18:29 ` Sergei Shtylyov
2007-07-07 18:39 ` Arnd Bergmann
2007-07-08 13:13 ` Segher Boessenkool
2007-07-08 20:36 ` Arnd Bergmann
2007-07-08 23:42 ` Segher Boessenkool
2007-07-09 12:43 ` Sergei Shtylyov
2007-07-09 14:43 ` Segher Boessenkool
2007-07-07 18:59 ` Sergei Shtylyov
2007-07-07 19:23 ` Arnd Bergmann
2007-05-15 16:32 ` [PATCH 3/5] Support for the LPC47M192 SuperIO on the MPC8641 HPCN Wade Farnsworth
2007-05-15 16:36 ` [PATCH 4/5] Add RTC CMOS support for " Wade Farnsworth
2007-05-15 16:50 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02 hardware Wade Farnsworth
2007-05-16 16:44 ` Jon Loeliger
2007-05-16 18:06 ` Wade Farnsworth
2007-05-18 6:52 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02 hardware Jin Zhengxiong-R64188
2007-05-21 15:59 ` Wade Farnsworth
2007-05-17 2:50 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware Zhang Wei-r63237
2007-05-17 16:03 ` Wade Farnsworth
2007-05-17 16:14 ` Kumar Gala
2007-05-17 16:58 ` Wade Farnsworth
2007-05-17 18:46 ` Timur Tabi
2007-05-17 18:48 ` Timur Tabi
2007-05-17 18:53 ` Scott Wood
2007-05-17 18:59 ` Timur Tabi
2007-05-17 19:16 ` Jerry Van Baren
2007-05-18 13:48 ` Matt Sealey
2007-05-17 22:34 ` Wade Farnsworth
2007-05-18 0:56 ` David Gibson
2007-05-18 3:49 ` Jerry Van Baren
2007-05-18 14:34 ` Timur Tabi
2007-05-18 15:22 ` Jerry Van Baren
2007-05-18 16:46 ` Scott Wood
2007-05-18 17:30 ` Jerry Van Baren
2007-05-18 17:39 ` Timur Tabi [this message]
2007-05-18 17:43 ` Scott Wood
2007-05-18 17:47 ` Timur Tabi
2007-05-18 17:52 ` Scott Wood
2007-05-18 17:56 ` Timur Tabi
2007-05-18 18:02 ` Scott Wood
2007-05-18 18:03 ` Jerry Van Baren
2007-05-18 18:19 ` Jon Loeliger
2007-05-18 18:23 ` Scott Wood
2007-05-18 19:05 ` Jon Loeliger
2007-05-18 19:09 ` Scott Wood
2007-05-18 18:30 ` Timur Tabi
2007-05-18 17:59 ` Jerry Van Baren
2007-05-18 10:20 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02hardware Zhang Wei-r63237
2007-05-21 16:01 ` Wade Farnsworth
2007-05-22 2:53 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon andRev1.02hardware Zhang Wei-r63237
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=464DE4C7.7030906@freescale.com \
--to=timur@freescale.com \
--cc=Wei.Zhang@freescale.com \
--cc=gerald.vanbaren@smiths-aerospace.com \
--cc=linuxppc-dev@ozlabs.org \
/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).