LKML Archive on
help / color / mirror / Atom feed
From: "Jon Smirl" <>
To: "Jean Delvare" <>
Cc: "Jochen Friedrich" <>,,
	"linuxppc-dev list" <>,, "Scott Wood" <>
Subject: Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
Date: Sun, 24 Feb 2008 11:19:28 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2/22/08, Jochen Friedrich <> wrote:
> Hi Jean,
>  >> +/*
>  >> + * Wait for patch from Jon Smirl
>  >> + * #include "powerpc-common.h"
>  >> + */
>  >
>  > It doesn't make sense to merge this comment upstream.
> I know you don't like the patch from Jon Smirl and you also explained your reasons.
>  Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
>  1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).

The correct statement is: modify the i2c subsystem to support the
standard kernel driver aliasing mechanism. Leaving powerpc and OF out
of the argument for the moment, i2c has a custom aliasing scheme on
the x86 too.

So as a first step, can we remove the custom i2c aliasing scheme and
change i2c to use standard module aliases on the x86? Patches for this
already exist.

On 2/23/08, Jean Delvare <> wrote:
> The problem I have with this is that it breaks compatibility. The chip
>  name is not only used for device/driver matching, it is also exported
>  to userspace as a sysfs attribute ("name"). Applications might rely on
>  it. At least libsensors does.

I think there is some confusion here. The OF aliases are only used by
the kernel to load the correct driver. Would doing something like this

static struct i2c_device_id pcf8563_id[] = {
	{"pcf8563", 0, "sysfs_legacy_name"},
	{"rtc8564", 0, "sysfs_legacy_name"},
	OF_ID("phillips,pcf8563", &pcf8563_id[0], 0)
	OF_ID("epson,rtc8564", &pcf8563_id[1], 0)
MODULE_DEVICE_TABLE(i2c, pcf8563_id);

Then in the probe function you can use the pointer to find the base id
entry and i2c never has to be aware that the OF alias exists.

>  2. record the I2c name in the dts tree, either as separate tag (like linux,i2c-name="<i2c-name>")

Not really practical for the millions of machines (all PowerPC Macs)
already shipped.

>    or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
>  3. use a glue layer with a translation map.

Audio codecs have exactly the same problem. There are probably other
devices that also need mapping.

This mapping table will need to contain a map from the OF names to the
kernel driver names.  It will need to stored permanently in RAM and
contain all possible mappings. This table will only grow in size.

The kernel has a widely used mechanism for mapping -- aliases in the
device drivers. Why do we want to build a new, parallel one?

What we are doing now is option 4.

4. Use kconfig to build custom kernels for each target system. Don't
load drivers automatically based on what the BIOS tells us.

Jon Smirl

      parent reply	other threads:[~2008-02-24 16:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31 12:54 Jochen Friedrich
2008-02-21 12:05 ` Jean Delvare
2008-02-22 11:16   ` Jochen Friedrich
2008-02-23 12:43     ` Jean Delvare
2008-03-25 18:46       ` Jochen Friedrich
2008-03-26  0:41         ` Stephen Rothwell
2008-02-23 21:28     ` Olof Johansson
2008-02-24 15:16       ` Jochen Friedrich
2008-02-24 18:15         ` Olof Johansson
2008-02-25 16:48           ` Jochen Friedrich
2008-02-24 16:19     ` 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:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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