On 10/15/07, Olof Johansson <[EMAIL PROTECTED]> wrote: > On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote: > > Adding the Linux expected device tree bindings to > > booting-without-of.txt seems to be getting a little unwieldy. Plus > > with more than one arch using the device tree (powerpc, sparc & > > microblaze) the device tree bindings aren't necessarily powerpc only > > (the Xilinx devices certainly fall in this category). > > > > Anyone have comments about splitting the expected device tree bindings > > out of booting-without-of.txt into a separate directory? > > The flat device tree is, in spite of what some people would like it to be, > not open firmware, nor is it the same as their bindings. So I think we'd > be doing ourselves a disservice by continuing to associate them together. > All it would take is a rename of the directory, unfortunately i don't > have any suggestions on better names though.
I think I need to stick with the of prefix. All the support API in include/linux/of_* is prefixed with "of_" already, so convention is established. How about Documentation/of-device-tree? > > > Perhaps something like this; each file contains common bindings for > > the type of device and device specific properties: > > > > Documentation/of/ > > Documentation/of/README - Description of the purpose and layout of > > this directory > > Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc) > > Documentation/of/serial.txt - serial device bindings > > Documentation/of/misc.txt - anything that doesn't fit anywhere else yet. > > Documentation/of/soc/* - System on chip stuff that doesn't fit will > > into established device types; possibly a separate file for each chip. > > Documentation/of/usb.txt - usb blah blah blah > > Documentation/of/whatever - you get the picture. > > > > Thoughts? > > Looks reasonable. The other way to cut it would be to slice along vendor > boundaries, but I think I like the functional partitioning you suggested > better. I think vendor partitioning makes sense for non-common devices that don't easily fit into a particular mold (soc glue nodes come to mind). Other than that, the functional partitioning lets us start with defining common property usage for a given device type and follow up with device specific properties. Thanks for the feedback, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
