linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: "Jon Smirl" <jonsmirl@gmail.com>
Cc: Linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
	i2c@lm-sensors.org
Subject: Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
Date: Tue, 1 Jul 2008 20:51:42 +0200	[thread overview]
Message-ID: <20080701205142.6fe73e80@hyperion.delvare> (raw)
In-Reply-To: <9e4733910807011027m5802cf76n3f68b8692ff6832f@mail.gmail.com>

On Tue, 1 Jul 2008 13:27:57 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
> >  > On 7/1/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > > > My preference is for things like of_spi and of_i2c to go with the
> >  > >  related busses; I think it makes more sense to keep all the I2C stuff
> >  > >  together, but I've already lost that battle once.
> >  >
> >  > This is a similar problem to adding aliases to the i2c driver drivers
> >  > for the device tree names of the i2c devices. Instead we have code in
> >  > drivers/of/of_i2c.c that tries to guess the translation from device
> >  > tree to linux names. Adding aliases to the drivers would eliminate the
> >  > need for of_find_i2c_driver().
> >  >
> >  > I've previously posted patches implementing device tree names in the
> >  > drivers that used ifdef to only instantiate on powerpc builds. For
> >  > example....
> >  >
> >  > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
> >  > index e07274d..9cd1770 100644
> >  > --- a/drivers/i2c/chips/tps65010.c
> >  > +++ b/drivers/i2c/chips/tps65010.c
> >  > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
> >  >         { "tps65011", TPS65011 },
> >  >         { "tps65012", TPS65012 },
> >  >         { "tps65013", TPS65013 },
> >  > +       OF_ID("ti,tps65010", TPS65010)
> >  > +       OF_ID("ti,tps65011", TPS65011)
> >  > +       OF_ID("ti,tps65012", TPS65012)
> >  > +       OF_ID("ti,tps65013", TPS65013)
> >  >         { },
> >  >  };
> >  >  MODULE_DEVICE_TABLE(i2c, tps65010_id);
> >
> >
> > Yeah, yeah, you've been asking for this for months already, but it's
> >  just not going to happen, sorry. You want to abuse the standard Linux
> >  alias mechanism for your personal (i.e. openfirmware) use, but that's
> >  bad. Linux drivers shouldn't have to know whether they are used in
> >  openfirmware trees and what device names are used there. And device
> >  names as seen by user-space shouldn't vary depending on whether the
> >  device comes from an openfirmware tree or not - otherwise all
> >  user-space apps need to learn about both naming conversions.
> >
> >  Unsurprisingly, no other subsystem does what you propose.
> 
> Then what are all of the PCI aliases doing?
> 
> The only difference is that you are recognizing the PCI group as a
> naming authority and not recognizing the PowerPC device tree group.
> But on the PowerPC platform that is our naming authority. That's why I
> proposed adding the names on ifdefs so that they disappear on non
> PowerPC platforms.

You're comparing PCI devices those ID is built-in, with I2C devices
with no ID. This just can't compare.

> PS - adding an alias to a driver does not change the name of the
> driver. My PCI e1000 module has about 100 aliases but it is always
> e1000.

I said device names, not driver names. Linux I2C devices have a name
attribute which contains the (Linux) device name. That's something a
number of user-space applications are relying on.

-- 
Jean Delvare

  parent reply	other threads:[~2008-07-01 18:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-30 23:01 [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4 Jon Smirl
2008-06-30 23:01 ` [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4 Jon Smirl
2008-07-01 15:05   ` Jean Delvare
2008-07-01 15:12     ` Jon Smirl
2008-07-01 16:29       ` Jean Delvare
2008-07-01 16:38         ` Jon Smirl
2008-07-01 16:44           ` Jean Delvare
2008-07-01 16:45         ` Grant Likely
2008-07-01 17:01           ` Jean Delvare
2008-07-01 17:06             ` Jon Smirl
2008-07-01 18:24               ` Jean Delvare
2008-07-01 16:43       ` Grant Likely
2008-07-01 17:00         ` Jon Smirl
2008-07-01 17:12           ` Jean Delvare
2008-07-01 17:27             ` Jon Smirl
2008-07-01 18:18               ` Jon Smirl
2008-07-01 18:51               ` Jean Delvare [this message]
2008-07-01 15:48     ` Jochen Friedrich
2008-07-01 16:29     ` Jon Smirl
2008-07-01 16:35       ` Jean Delvare
2008-07-01 16:14 ` [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4 Jean Delvare
2008-07-02 13:33   ` [i2c] " Wolfram Sang
2008-07-02 14:36     ` Jean Delvare
2008-07-09 17:22 ` Grant Likely
2008-07-10 16:36   ` Timur Tabi
2008-07-11 18:12     ` Grant Likely
2008-07-11 18:45       ` Anton Vorontsov
2008-07-11 18:54         ` Grant Likely

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=20080701205142.6fe73e80@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=i2c@lm-sensors.org \
    --cc=jonsmirl@gmail.com \
    --cc=paulus@samba.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).