+
+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/
Thats true, "device nodes" makes sense.
+
+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?
Opps..
I remember fixing this, I will take care of it in next version.
+ 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.
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.
reg-names inside the "data cells" is ok, but I can't think of its use
immediately. May be useful for debug?
--srini
>
Rob
+
+For example:
+
+ tsens {
+ ...
+ eeproms = <&tsens_calibration>;
+ eeprom-names = "calibration";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
