Re: Refactor booting-without-of.txt

["Grant Likely" <grant.likely@secretlab.ca>]

On 10/15/07, Olof Johansson <olof@lixom.net> 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.
grant.likely@secretlab.ca
(403) 399-0195