From: David Gibson <david@gibson.dropbear.id.au>
To: Jean Delvare <khali@linux-fr.org>
Cc: linuxppc-dev@ozlabs.org, Stefan Roese <sr@denx.de>, i2c@lm-sensors.org
Subject: Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
Date: Wed, 17 Oct 2007 10:37:08 +1000 [thread overview]
Message-ID: <20071017003708.GC28260@localhost.localdomain> (raw)
In-Reply-To: <20071016211939.250c2da4@hyperion.delvare>
On Tue, Oct 16, 2007 at 09:19:39PM +0200, Jean Delvare wrote:
> On Mon, 15 Oct 2007 22:21:38 -0600, Grant Likely wrote:
> > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > In fact I think it may be acceptle to do the idx++ thing in this
> > > situation. Bus numbers are ugly, but it's not the worst ugliness in
> > > the horrible mess that is the Linux i2c subsystem. It means that bus
> > > numbers are theoretically unstable, but that's increasingly true of
> > > devices of all sorts - it's up to udev to assign meaningful labels at
> > > the user level.
>
> David, after such a rant against the Linux i2c subsystem, I sure hope
> that you're going to contribute patches to make it better (whatever you
> think needs to be improved, as you didn't say.)
I've frequently contemplated it. In the unlikely event that it ever
bubbles to the top of my priorities, I might well.
> > I think the real problem here comes into play when there are 2 types
> > of i2c busses in the system. If they both maintain their own idx++
> > values; then they will conflict. If an auto assigned bus number is
> > used; then it needs to be assigned by the i2c infrastructure; not by
> > the driver.
>
> Very true. If you aren't going to define the i2c bus numbers at
> platform data level, then you shouldn't be defining them _at all_.
> Don't use i2c_add_numbered_adapter, use i2c_add_adapter and let
> i2c-core choose an appropriate a bus number.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2007-10-17 0:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-15 13:29 [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx Stefan Roese
2007-10-15 16:32 ` Eugene Surovegin
2007-10-15 16:57 ` Grant Likely
2007-10-15 18:53 ` Scott Wood
2007-10-15 19:11 ` Eugene Surovegin
2007-10-15 19:16 ` Grant Likely
2007-10-15 19:18 ` Scott Wood
2007-10-15 19:13 ` Grant Likely
2007-10-15 19:24 ` Scott Wood
2007-10-15 19:48 ` Grant Likely
2007-10-15 19:54 ` Scott Wood
2007-10-15 20:26 ` Grant Likely
2007-10-15 20:45 ` Scott Wood
2007-10-16 3:20 ` David Gibson
2007-10-16 4:21 ` Grant Likely
2007-10-16 19:19 ` Jean Delvare
2007-10-17 0:37 ` David Gibson [this message]
2007-10-15 16:46 ` Grant Likely
2007-10-19 11:56 ` Valentine Barshak
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=20071017003708.GC28260@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=i2c@lm-sensors.org \
--cc=khali@linux-fr.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=sr@denx.de \
/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.