Thats true, "device nodes" makes sense.+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@00700000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00700000 0x1000>;
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
+
+ serial_number: sn {
+ reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are drivers which consume eeprom data cells.
s/drivers/device nodes/
Opps..+
+Required properties:
+
+eeproms: List of phandle and data cell the device might be interested in.
+
+Optional properties:
+
+eeprom-names: List of data cell name strings sorted in the same order
+ as the resets property. Consumers drivers will use
resets?
Yes, eeprom-names is needed in the consumer nodes, where there are multiple eeproms cells, its easy to lookup by name rather than index,which depends on the order of the entries.
+ eeprom-names to differentiate between multiple cells,
+ and hence being able to know what these cells are for.
Is this still needed? The sub-node name defines the name. Or you can
use reg-names with-in the sub-node.
--
Rob
+
+For example:
+
+ tsens {
+ ...
+ eeproms = <&tsens_calibration>;
+ eeprom-names = "calibration";
+ };
--
1.9.1