Re: Schemas for device trees

["jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

i2c provides an example of where a schema would be useful.
>From the binding text files, I removed the common items

fsl-i2c
	i2c@1740 {
		clock-frequency = <100000>;
		fsl,timeout = <10000>;
	};
samsung-i2c
	i2c@13870000 {
		samsung,i2c-sda-delay = <100>;
		samsung,i2c-max-bus-freq = <100000>;
		samsung,i2c-slave-addr = <0>;
	};
ce4100-i2c.txt
	i2c@0 {
missing clock-frequency
	};
omap-i2c.txt
i2c1: i2c@0 {
    ti,hwmods = "i2c1";   -- I think this is because they are missing reg = <>
    clock-frequency = <400000>;
};
arm-versatile.txt
missing clock frequency
i2c-designware.txt
looks ok
fsl-imx-i2c.txt
looks ok
cpm_qe/cpm/i2c.txt
file is in wrong place

The schema probably should be:
	i2c@address {
		compatible = "xxxx";  - required
		reg = <xxxx>; - required
		interrupts = <xxx>;  - required?
		interrupt-parent = <xxxx>; - if need
		clock-frequency = <xxxx>;  - optional, schema says default is 100Khz
		slave-addr = <xxxx>;  - optional, all of the controllers support slave mode
		timeout = <xxxxx>; - optional
		#address-cells = <1>;
		#size-cells = <0>;
		aaaa,bbbb = <xxxx> - private, must have a comma in the name
      }

Once schemas are in place and everything is validating, another pass
can be made to implement a common parser. The common parser would get
all of these attributes and parse them into a struct.  Then we can
work on making sure each driver actually implements these core
attributes consistently.

-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org