Compound devices that actually have their own shared registers should do something different. Likely they'll need some sort of data synchronization anyway. It seems that by far the common case here is to going to be to just have aggregation, and I don't see any reason that can't be handled by a common 'pseudo-bus'.
Steve -----Original Message----- From: [EMAIL PROTECTED] on behalf of Grant Likely Sent: Sun 12/16/2007 8:30 PM To: Stephen Neuendorffer; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of. On 12/16/07, David Gibson <[EMAIL PROTECTED]> wrote: > On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote: > > This now better describes what the UBoot device tree generator actually > > does. In particular: > > > > 1) Nodes have a label derived from the device name, and a node name > > derived from the device type. > > 2) Usage of compound nodes (representing more than one device in the same > > IP) which actually works. This requires having a valid compatible node, > > and all the other things that a bus normally has. I've chosen > > 'xlnx,compound' as the bus name to describe these compound nodes. > > I'm not sure I like this xlnx,compound business, although maybe it's > the best you can do. I'd prefer something like "xlnx,<ip-name>-group". "xlnx,compound" is a very bad idea because it will be reused for very different types of devices. What happens when a device appears that has both per-instance properties and 'top level' registers accessed by both devices?
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev