[PATCH] of: i2c: improve last resort compatible entry selection

[Segher Boessenkool]

>>> compatible = "atmel,24c32wp", "24c32", "eeprom";

>> I know this is just an example; but to keep thinks clear, the second
>>  and third values in this compatible property are completely bogus 
>> (for
>>  device trees).  The manufacturer prefix needs to be present and
>>  'eeprom' is far to vague.
>
> Isn't 24c32 a generic, cross manufacturer term used for these devices?

Sure it is.  But "compatible" values are a global namespace so care
needs to be taken not to cause collisions.  One mechanism for that
is to use vendor prefixes (and that just shifts the problem so it
is less global); another is to choose good names that have a lower
chance to collide with the name for another device.  And the most
important way to prevent collisions is to write up a binding, so
everyone knows you have claimed that name.  It still needs to be
a good name, of course.

> What if I have a socket and use a different vendor's chip each week?

You use sockets for your seeproms?  Wow :-)  But yes, it shouldn't
be necessary to put the exact make of the device in the device
tree, for such generic devices.  It certainly doesn't hurt to do
so though (if the exact model is known).

A reasonable "compatible" value would be something like 
"serial-eeprom-24c32".
You can go a little bit more generic than that, if you write up in
your binding how the driver should figure out the device size and
the protocol used.

> eeprom is the vague Linuxism that at24 is attempting to correct.
> eeprom just goes and searches for anything resembling an eeprom. It
> will trigger on chips that aren't eeproms.

Yeah.  And no driver should need to probe _anything_ if it has a
device tree node describing the device -- certainly it shouldn't
probe for what kind of device it is!


Segher