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

[EMAIL PROTECTED]
        device_type="rtc";
        compatible="nxp,pcf8563";
        reg=<0x51>;
};

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

i2c_0 {
        [EMAIL PROTECTED]
                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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to