On Sun, Feb 22, 2015 at 8:32 AM, Maxime Ripard
[off-list ref] wrote:

On Fri, Feb 20, 2015 at 04:01:55PM -0600, Rob Herring wrote:

quoted

[...]

quoted

quoted

quoted

+= Data consumers =
+
+Required properties:
+
+eeproms: List of phandle and data cell specifier triplet, one triplet
+        for each data cell the device might be interested in. The
+        triplet consists of the phandle to the eeprom provider, then
+        the offset in byte within that storage device, and the length
+        in byte of the data we care about.

The problem with this is it assumes you know who the consumer is and
that it is a DT node. For example, how would you describe a serial
number?

Correct me if I miss understood.
Is serial number any different?
Am hoping that the eeprom consumer would be aware of offset and size of
serial number in the eeprom

Cant the consumer do:

eeprom-consumer {
        eeproms = <&at24 0 4>;
        eeprom-names = "device-serial-number";

Yes, but who is "eeprom-consumer"?

Any device that should lookup values in one of the EEPROM.

quoted

DT nodes generally describe a h/w block, but it this case, the
consumer depends on the OS, not the h/w.

Not really, or at least, not more than any similar binding we
currently have.

The fact that a MAC-address for the first ethernet chip is stored at a
given offset in a given eeprom has nothing to do with the OS.

So MAC address would be a valid use to link to a h/w device, but there
are certainly cases that don't correspond to a device.

quoted

I'm not saying you can't describe where things are, but I don't
think you should imply who is the consumer and doing so is
unnecessarily complicated.

If you only take the case of a serial number, indeed. If you take
other usage into account, you can't really do without it.

quoted

Also, the layout of EEPROM is likely very much platform specific.

Indeed, which is why it should be in the DT.

Agreed. I'm not saying the layout should not be.

quoted

Some could have a more complex structure perhaps with key ids and
linked list structure.

Then just request the size of the whole list, and parse it afterwards
in your driver?

quoted

I would do something more simple that is just a list of keys and their
location like this:

device-serial-number = <start size>;
key1 = <start size>;
key2 = <start size>;

I'm sorry, but what's the difference?

It can describe the layout completely whether the fields are tied to a
h/w device or not.

What I would like to see here is the entire layout described covering
both types of fields.

Rob