Merging seperate FDT-blobs?

[Wolfram Sang]

On Mon, Jul 07, 2008 at 11:28:43AM +1000, David Gibson wrote:

> > This function is surely needed in every case I considered so far. I am
> > just sceptical if the boot-loader can determine a correct parentoffset
> > all alone (which one of the two I2C busses is the correct one?). This is
> 
> Hrm.  "all alone".  It's not clear to me what else there could be that
> would have more information than the bootloader.

What I meant is that all the information a bootloader has may not be
sufficent. To solve this, some additional infos could be added to the
tree. In this case, it could be a few aliases.

> > What I encoded using "external-name" is where possible fragments
> > _could_ be added to. Something like a mount-point. The boot-loader
> > decides if and what could be mounted there. As an "/aliases" node is
> > already in use, I would favour to add such mount-points there.
> 
> Hrm.  I'm not convinced that the mount point model is actually a good
> one.  I would have thought that one of the most common things to graft
> would be extra optional devices onto a bus.  In this case there's no
> specific "mountpoint"  the device could be attached at any valid
> address on the bus in question.

Maybe I am really missing something here, but what is the bus in
question? How do you tell from such an entry

rtc at 51{
	device_type="rtc";
	compatible="nxp,pcf8563";
	reg=<0x51>;
};

if it is connected to "/pci/pci_bridge/isa" as in mpc8548cds.dts or to
"/soc5200/i2c at 3d40" as in pcm030.dts? The latter even has another
I2C-bus i2c at 3d00 which could also be a possibility. This is why I'd like
to encode the fragment as:

i2c_0 {
	rtc at 51{
		device_type="rtc";
		compatible="nxp,pcf8563";
		reg=<0x51>;
	};
};

with i2c_0 being an alias to the proper bus. Maybe I should add that I
am _not_ assuming that the fragment is obtained from the bus which wants to
have devices added. That is, one I2C-eeprom may contain data about
additional devices on PCI.

Kind regards,

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080707/f5a2f112/attachment.pgp>