LKML Archive on
help / color / mirror / Atom feed
From: Jean Delvare <>
To: "Jon Smirl" <>
Subject: Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
Date: Sun, 13 Jan 2008 16:09:46 +0100	[thread overview]
Message-ID: <20080113160946.5cddc813@hyperion.delvare> (raw)
In-Reply-To: <>

Hi Jon,

On Sat, 12 Jan 2008 11:00:31 -0500, Jon Smirl wrote:
> On 1/12/08, Jean Delvare wrote:
> > 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.
> Those dts files are for embedded devices that were specifically
> developed for Linux. All of the PowerPC Macs in the world have a
> device tree in ROM that was developed by Apple following the Open
> Firmware standard. Same thing for Sun boxes, but I'm not working on
> those.

OK. So basically we have to handle two different cases here, trees that
come from the .dts files and trees that are read from ROMs, right?
Does this mean that .dts files are compiled to some binary format to
look like what is in the ROMs? Is there kernel code that parses this?
Please explain how both types are handled by the kernel. I need to
understand how this works before I can decide where the OF names ->
Linux names translation can happen.

> The kernel has an existing mechanism for handling translations like
> these, the alias scheme.

That we agree on. My concern here is that you want to replace the Linux
names of i2c devices by OF names, without realizing that the Linux
names have a use outside of the kernel. We can't just replace them like
that, it would break some user-space applications. That's the reason
why I believe that it would make more sense to translate from OF names
to Linux names early in the process, so that the kernel, and thus
user-space applications, always handle and see the Linux names,
independently of the platform. I'm asking questions in order to figure
out whether and how this could be achieved.

> Currently developers add entries to the table in their private builds
> for the i2c devices they are using. Another way to avoid adding a
> table entry is to create a platform device in the platform code. But
> this support is being extended to audio codecs too. There are hundreds
> of audio codecs.
> The whole purpose of this code is to dynamically load the correct i2c
> and audio drivers by reading the device tree instead of having static
> i2s/codec devices for every possible platform combination.

I2C driver autoloading is already implemented, and works. Just not the
way you expected, but it works.

Replacing this mechanism with standard aliases is IMHO a good idea, it
makes the code cleaner and also more similar to what the rest of the
kernel does, which is always nice.

However, having a module aliasing mechanism for i2c drivers does NOT
require that OF names are used. We could implement aliasing using Linux
device names. Note that I have no problem with using OF names for
aliasing, however it should not break applications that currently know
the I2C devices by their Linux name.

Jean Delvare

      reply	other threads:[~2008-01-13 15:09 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
2008-01-12 16:00           ` Jon Smirl
2008-01-13 15:09             ` Jean Delvare [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:

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

  git send-email \
    --in-reply-to=20080113160946.5cddc813@hyperion.delvare \ \ \ \ \ \

* 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).