From: Olof Johansson <olof@lixom.net>
To: Jochen Friedrich <jochen@scram.de>
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: Sun, 24 Feb 2008 12:15:10 -0600 [thread overview]
Message-ID: <20080224181509.GA6745@lixom.net> (raw)
In-Reply-To: <47C18A4E.5080804@scram.de>
Hi,
On Sun, Feb 24, 2008 at 04:16:30PM +0100, Jochen Friedrich wrote:
> Hi Olof,
>
> >> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
> >> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
> >
> > I have to say no on this one. The device tree is not supposed to know
> > about how linux uses devices, there are firmwares out there that don't
> > use DTS for thier device trees, etc.
>
> I still believe this this could be done for embedded devices which are usually booted
> via wrapper or U-Boot as those devices will most probably use the most exotic I2c devices
> out there (e.g. home-grown devices used by stbs). However, I'm not an device tree expert.
Sorry, but you're wrong in your assumptions. Not all embedded devices
use U-boot, and not all use the wrapper. It's just a bad idea to encode
linux-specific things in the device tree, period.
And even if you DO decide to go that route, guess what? You need a
translation table just as with (3) anyway!
> >> 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?
-Olof
WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net>
To: Jochen Friedrich <jochen@scram.de>
Cc: Jean Delvare <khali@linux-fr.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>,
linux-kernel@vger.kernel.org,
Scott Wood <scottwood@freescale.com>,
i2c@lm-sensors.org
Subject: Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
Date: Sun, 24 Feb 2008 12:15:10 -0600 [thread overview]
Message-ID: <20080224181509.GA6745@lixom.net> (raw)
In-Reply-To: <47C18A4E.5080804@scram.de>
Hi,
On Sun, Feb 24, 2008 at 04:16:30PM +0100, Jochen Friedrich wrote:
> Hi Olof,
>
> >> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
> >> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
> >
> > I have to say no on this one. The device tree is not supposed to know
> > about how linux uses devices, there are firmwares out there that don't
> > use DTS for thier device trees, etc.
>
> I still believe this this could be done for embedded devices which are usually booted
> via wrapper or U-Boot as those devices will most probably use the most exotic I2c devices
> out there (e.g. home-grown devices used by stbs). However, I'm not an device tree expert.
Sorry, but you're wrong in your assumptions. Not all embedded devices
use U-boot, and not all use the wrapper. It's just a bad idea to encode
linux-specific things in the device tree, period.
And even if you DO decide to go that route, guess what? You need a
translation table just as with (3) anyway!
> >> 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?
-Olof
next prev parent reply other threads:[~2008-02-24 18:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-31 12:54 [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers Jochen Friedrich
2008-01-31 12:54 ` Jochen Friedrich
2008-02-21 12:05 ` Jean Delvare
2008-02-21 12:05 ` Jean Delvare
2008-02-22 11:16 ` Jochen Friedrich
2008-02-22 11:16 ` Jochen Friedrich
2008-02-23 12:43 ` Jean Delvare
2008-02-23 12:43 ` Jean Delvare
2008-03-25 18:46 ` Jochen Friedrich
2008-03-25 18:46 ` Jochen Friedrich
2008-03-26 0:41 ` Stephen Rothwell
2008-03-26 0:41 ` Stephen Rothwell
2008-02-23 21:28 ` Olof Johansson
2008-02-23 21:28 ` Olof Johansson
2008-02-24 15:16 ` Jochen Friedrich
2008-02-24 15:16 ` Jochen Friedrich
2008-02-24 18:15 ` Olof Johansson [this message]
2008-02-24 18:15 ` Olof Johansson
2008-02-25 16:48 ` Jochen Friedrich
2008-02-25 16:48 ` Jochen Friedrich
2008-02-24 16:19 ` Jon Smirl
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=20080224181509.GA6745@lixom.net \
--to=olof@lixom.net \
--cc=i2c@lm-sensors.org \
--cc=jochen@scram.de \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.