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"? > > > 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 > > -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
