On 10/15/07, Olof Johansson [off-list ref] wrote:

On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:

quoted

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?

quoted

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.
grant.likely@secretlab.ca
(403) 399-0195