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

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

[Grant Likely]

On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote:
>>>  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.
>
> No, it requires the IIC subsystem to get fixed and not use OF
> "compatible" values as module alias names.

Indeed; the device tree is just a data structure with a well defined
usage model.  It is the kernel's job to adapt that data into a form that
it can use.

>> How
>> about "serial-eeprom,24c32" or "generic,24x32"?
>
> Neither "serial-eeprom" nor "generic" is the name of a vendor, so
> no.  The comma has a well-defined meaning.  Why would a comma be
> easier than a dash for your device matching code, anyway?

Just to add my voice; I 100% agree.  If it is not documented, and it
doesn't fit with established conventions, then it shouldn't be used in
the compatible field.

g.

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

[Jon Smirl]

On 7/30/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote:
>  >>>  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.
>  >
>  > No, it requires the IIC subsystem to get fixed and not use OF
>  > "compatible" values as module alias names.
>
>
> Indeed; the device tree is just a data structure with a well defined
>  usage model.  It is the kernel's job to adapt that data into a form that
>  it can use.

Then we're going to have to work on the i2s subsystem more to get them
to allow arbitrary modalias strings like serial-eeprom-24c32.

The current i2c code has linked the use of modalias strings and the
i2c sysfs attribute  'name'. Currently those two always need to be the
same. Existing user space apps are expecting to get the linux name for
the device from the name field.  That linkage needs to be broken.

Then you need entries like this:

static const struct i2c_device_id at24_ids[] = {
	{ "24c01", "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
	{ "24c02", "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
	OF( "serial-eeprom-24c01", "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) ),
	OF( "serial-eeprom-24c02", "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) ),

First column is the modalias, second is the string that is going into
the 'name' attribute. OF() causes the entries to disappear on non-OF
platforms.

We should argue for another macro that makes the non-OF strings
disappear on our platform.

I have submitted a patch like this before and Jean declared that he
doesn't recognize open firmware as a naming authority and NACK'd it.


>
>
>  >> How
>  >> about "serial-eeprom,24c32" or "generic,24x32"?
>  >
>  > Neither "serial-eeprom" nor "generic" is the name of a vendor, so
>  > no.  The comma has a well-defined meaning.  Why would a comma be
>  > easier than a dash for your device matching code, anyway?
>
>
> Just to add my voice; I 100% agree.  If it is not documented, and it
>  doesn't fit with established conventions, then it shouldn't be used in
>  the compatible field.
>
>
>  g.
>


-- 
Jon Smirl
jonsmirl@gmail.com