LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: "Jon Smirl" <jonsmirl@gmail.com>
Cc: i2c@lm-sensors.org, linuxppc-dev@ozlabs.org,
	linux-kernel@vger.kernel.org
Subject: Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
Date: Sat, 12 Jan 2008 10:08:35 +0100	[thread overview]
Message-ID: <20080112100835.616d6bd9@hyperion.delvare> (raw)
In-Reply-To: <9e4733910801111216g7dfee16ev72ec3c58e5d6c746@mail.gmail.com>

On Fri, 11 Jan 2008 15:16:57 -0500, Jon Smirl wrote:
> On 1/11/08, Jean Delvare <khali@linux-fr.org> wrote:
> > Secondly, it promotes OF device names as acceptable aliases. This I
> > don't think I agree with. While I see some value in moving the OF name
> > -> Linux name translation to the drivers themselves (even though I
> > don't see this as a mandatory move either), this doesn't imply that OF
> > names should be used as aliases. I don't like the idea that different
> > architectures will name the same device differently in a visible way.
> > This could easily break user-space code that makes assumptions on the
> > device names (libsensors comes to mind.) So, I think that this part
> > will need some more discussion.
> 
> They're aliases.  On the x86 my e1000 Ethernet driver loads using this
> alias name:
> "pci:v00008086d00001010sv*sd*bc*sc*i*"
> In fact, the e1000 driver has 63 alias names in addition to "e1000"
> 
> But it's still the e1000 driver after it is loaded.
> jonsmirl@terra:/home/linux/drivers/net/e1000$ lsmod | grep e1000
> e1000                 115968  0
> 
> Loading a I2C driver with an OF alias name is not going to change the
> module name after it is loaded. In fact, once the module is in memory
> there's no way to tell what name was used to load it.

Of course. That's not what I was worried about... what I was worried
about is something your patch set doesn't do but I misread the code and
I thought it was doing. I'll read it again before I make more comments
on this.

> OF device names are set by the Open Firmware committee. It is not
> reasonable to force the Linux names back into Open Firmware since this
> would force the other operating systems using Open Firmware to adopt
> the Linux names.

I never meant to force the Linux names into Open Firmware. It wouldn't
make sense especially when the Linux names are invented by random
contributors with no specific rules, and can even change over time.

What I meant is that the translation from Open Firmware device name to
Linux device name could happen in different ways. Making module aliases
out of the is one possibility but this is not the only one.

I am curious why the translation could not happen "offline". As I
understand it, you're getting the device names from these .dts files.
However you're not parsing them in the kernel directly, are you? I
presume that you have some tool that converts these files into C code
that the kernel can use? This conversion tool could translate the names.

> This issue hasn't been visible before since there was a global table
> in the PowerPC code mapping all known Open Firmware names into linux
> names. Keeping this as a global table doesn't scale. The mapping needs
> to be done by each device individually.

Looking at your patch set, I see only 11 entries in the table (in
arch/powerpc/sysdev/fsl_soc.c) that patch #2 deletes. Are there more in
other files? I'm asking because 11 entries hardly qualifies as "doesn't
scale". I sure hope that you're not doing all this for the sole purpose
of getting rid of this 11-element table.

-- 
Jean Delvare

  reply	other threads:[~2008-01-12  9:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-20  4:41 [PATCH 0/5] Version 17, series to add device tree naming to i2c Jon Smirl
2007-12-20  4:41 ` [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names Jon Smirl
2008-01-11 19:20   ` [i2c] " Jean Delvare
2008-01-12  8:46     ` Jean Delvare
2008-01-12 16:26       ` Jon Smirl
2008-01-13 14:41         ` Jean Delvare
2008-01-13 16:24           ` Jon Smirl
2008-01-13 17:40             ` Jean Delvare
2008-01-13 18:01               ` Jon Smirl
2008-01-13 18:45                 ` Jean Delvare
2008-01-13 18:50                   ` Jon Smirl
2008-01-13 19:05                     ` Jean Delvare
2007-12-20  4:41 ` [PATCH 2/5] Modify several rtc drivers to use the alias names list property of i2c Jon Smirl
2007-12-20  4:41 ` [PATCH 3/5] Clean up error returns Jon Smirl
2007-12-20  4:41 ` [PATCH 4/5] Convert PowerPC MPC i2c to of_platform_driver from platform_driver Jon Smirl
2007-12-20  5:16   ` David Gibson
2007-12-20  6:01     ` Olof Johansson
2007-12-20  6:04     ` Stefan Roese
2007-12-20 15:56     ` Jon Smirl
2007-12-20  4:41 ` [PATCH 5/5] Convert pfc8563 i2c driver from old style to new style Jon Smirl
2007-12-20 23:59 ` [PATCH 0/5] Version 17, series to add device tree naming to i2c Jon Smirl
2007-12-27 16:47 ` Jon Smirl
2007-12-28 12:14   ` Jean Delvare
2008-01-11  8:56 ` [i2c] " Jean Delvare
2008-01-11 15:52   ` Jon Smirl
2008-01-11 16:05     ` Jochen Friedrich
2008-01-11 19:15     ` Jean Delvare
2008-01-11 20:16       ` Jon Smirl
2008-01-12  9:08         ` Jean Delvare [this message]
2008-01-12 16:00           ` Jon Smirl
2008-01-13 15:09             ` Jean Delvare

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=20080112100835.616d6bd9@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=i2c@lm-sensors.org \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --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).