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=20
helpful.   Take another example:

Say you-- a human reader-- see this in a device
tree:

...
interrupts =3D <b 8>;
interrupt-parent =3D < &mpic >;
...

What does the 'b' and '8' mean?  You look
at the interrupt controller node--

  mpic: pic@40000 {
     clock-frequency =3D <0>;
     interrupt-controller;
     #address-cells =3D <0>;
     #interrupt-cells =3D <2>;
     reg =3D <40000 40000>;
     compatible =3D "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 =3D "open-pic"; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.

Stuart