LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jochen Friedrich <jochen@scram.de>
To: Olof Johansson <olof@lixom.net>
Cc: Jean Delvare <khali@linux-fr.org>,
	linux-kernel@vger.kernel.org,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	i2c@lm-sensors.org, Scott Wood <scottwood@freescale.com>
Subject: Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale	CPM1/CPM2 controllers
Date: Mon, 25 Feb 2008 17:48:27 +0100	[thread overview]
Message-ID: <47C2F15B.8070703@scram.de> (raw)
In-Reply-To: <20080224181509.GA6745@lixom.net>

Hi Olof,

> And even if you DO decide to go that route, guess what? You need a
> translation table just as with (3) anyway!

True.

>>>> 3. use a glue layer with a translation map.
>>> In my opinion this is an OK solution since the same information has to
>>> be added somewhere already anyway -- eiither to the drivers or to this
>>> translation table. It should of course be an abstacted shared table,
>>> preferrably contained under the i2c source directories since several
>>> platforms and architectures might share them.
>> I could think of a mixture between 2. and 3.:
>>
>> Using the compatible attribute with the manufacturer stripped off as I2c name by default
>> and using an exception table. For now, the struct i2c_driver_device would currently only
>> need one entry ("dallas,ds1374", "rtc-ds1374").
> 
> You still need the translation table, you're just flattening the
> namespace to one string instead of two, the same information still has
> to be encoded. I can't see what the benefit of this approach compared to
> the other one is. "dallas,ds1374" already only has one translation entry
> in the table?

As soon as http://lists.lm-sensors.org/pipermail/i2c/2008-January/002752.html has been
applied, one could get rid of all entries where the I2c (alias) name can be obtained from
the OF name just by stripping the manufacturer.

Thanks,
Jochen

  reply	other threads:[~2008-02-25 18:35 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 [this message]
2008-02-24 16:19     ` Jon Smirl

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=47C2F15B.8070703@scram.de \
    --to=jochen@scram.de \
    --cc=i2c@lm-sensors.org \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=olof@lixom.net \
    --cc=scottwood@freescale.com \
    --subject='Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale	CPM1/CPM2 controllers' \
    /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

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