In message: <[EMAIL PROTECTED]>
"Jon Smirl" <[EMAIL PROTECTED]> writes:
: On 7/27/08, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
: > >
: > > >
: > > > > 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.
:
: Matching on "serial-eeprom-24c32" requires me to convince the at24
: authors to add that string as an alias binding for their driver. How
: about "serial-eeprom,24c32" or "generic,24x32"?
Many of the serial eeproms have a common way to access them. There's
a few organizations of eeproms made by a number of different
manufacturers that are actually accessed the same.
Warner
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
