On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
>
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
>
> Don't know how cute it is, but I think it is practically
> helpful. Take another example:
>
> Say you-- a human reader-- see this in a device
> tree:
>
> ...
> interrupts = <b 8>;
> interrupt-parent = < &mpic >;
> ...
>
> What does the 'b' and '8' mean? You look
> at the interrupt controller node--
>
> mpic: [EMAIL PROTECTED] {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <40000 40000>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
>
> device_type = "open-pic"; makes it perfectly clear.
> It's an open-pic type controller and follows that
> binding.
That's an extremely contrived example - it only works because for
historical reasons the "open-pic" device_type describes a programming
model as well as an OF method interface. In general, you always need
to look at a node's "compatible" and the binding for that to work out
what it's properties mean, or if it's an interrupt controller what the
format of its interrupt specifiers is.
open-pic is the *only* example I can think of where device_type will
tell you this. In fact, "open-pic" really belongs in compatible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
