linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Jon Smirl" <jonsmirl@gmail.com>
To: "Grant Likely" <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@ozlabs.org
Subject: Re: [PATCH] of: i2c: improve last resort compatible entry selection
Date: Wed, 30 Jul 2008 16:20:50 -0400	[thread overview]
Message-ID: <9e4733910807301320h4e6029a8gbff2875ba9c7ab0b@mail.gmail.com> (raw)
In-Reply-To: <20080730144202.GB21958@secretlab.ca>

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

      reply	other threads:[~2008-07-30 20:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-14 17:54 [PATCH] of: i2c: improve last resort compatible entry selection Anton Vorontsov
2008-07-15 10:44 ` Jochen Friedrich
2008-07-15 13:40   ` Jon Smirl
2008-07-15 14:05     ` Jean Delvare
2008-07-15 14:52       ` Jochen Friedrich
2008-07-15 15:39         ` Jean Delvare
2008-07-27  0:11 ` Grant Likely
2008-07-27  5:05   ` Jon Smirl
2008-07-27  5:35     ` Grant Likely
2008-07-27 14:21       ` Jon Smirl
2008-07-27 21:52         ` Segher Boessenkool
2008-07-27 22:00           ` Jon Smirl
2008-07-28  4:16             ` M. Warner Losh
2008-07-28  7:47             ` Segher Boessenkool
2008-07-30 14:42               ` Grant Likely
2008-07-30 20:20                 ` Jon Smirl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e4733910807301320h4e6029a8gbff2875ba9c7ab0b@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).