All of 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: Sun, 24 Feb 2008 16:16:30 +0100	[thread overview]
Message-ID: <47C18A4E.5080804@scram.de> (raw)
In-Reply-To: <20080223212823.GA22131@lixom.net>

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

Thanks,
Jochen

WARNING: multiple messages have this Message-ID (diff)
From: Jochen Friedrich <jochen@scram.de>
To: Olof Johansson <olof@lixom.net>
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 16:16:30 +0100	[thread overview]
Message-ID: <47C18A4E.5080804@scram.de> (raw)
In-Reply-To: <20080223212823.GA22131@lixom.net>

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

Thanks,
Jochen

  reply	other threads:[~2008-02-24 15:16 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 [this message]
2008-02-24 15:16         ` Jochen Friedrich
2008-02-24 18:15         ` Olof Johansson
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=47C18A4E.5080804@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 \
    /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.