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

[Jon Smirl]

On 7/27/08, Segher Boessenkool <segher at kernel.crashing.org> 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
jonsmirl at gmail.com