All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Jean Delvare <khali@linux-fr.org>,
	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: Mon, 15 Oct 2007 14:24:14 -0500	[thread overview]
Message-ID: <4713BE5E.3030406@freescale.com> (raw)
In-Reply-To: <fa686aa40710151213r670bea49i63fa5f5402aa150d@mail.gmail.com>

Grant Likely wrote:
> On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
>> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
>>> Segher is recommending that we use an aliases node as per the open
>>> firmware example for this.  I think in this case it would look
>>> something like this (but I'm not the expert):
>>>
>>> aliases {
>>>      IIC0 = "/path/to/bus/iic@0x2000";
>>>      IIC1 = "/path/to/bus/iic@0x2000";
>>> };
>> I think this is overly complicated; something like linux,i2c-index in the
>> i2c adapter node would be simpler.
> 
> But not perhaps better.  Enumeration is a system-wide thing.  It does
> make sense to group all the device enumerations in one place.

For purposes of generating a Linux bus number, having to scan all 
aliases for a matching path and turn IIC0/IIC1 into a number is a bit silly.

For associating a device node with a human readable label, I'd prefer a 
"label" property in the device node, rather than doing it backwards with 
aliases.

> As per your point below; if all the i2c devices are children of the
> adapter, then yes you are right that the bus number doesn't matter to
> the user.  But it *does* matter for things like serial and ethernet
> ports.

And a label property would be great for that. :-)

>> Though, I don't see what the problem with the original approach is, as long
>> as the numbers are chosen in the same way when registering i2c clients based
>> on the children of the adapter node.  There's no concept in the hardware
>> itself of a bus number.
> 
> Even if you take this approach, the driver still need to know what bus
> number to use (as per the i2c infrastructure).  It is not sane for an
> i2c bus driver to attempt to assign the bus number itself because it
> could conflict with another arbitrarily chosen bus number from another
> driver.

Hence why global bus numbers suck. :-)

However, statically chosen numbers should only be done for platform 
devices, not dynamic things such as PCI, so in practice I don't think 
it'd be a problem.

-Scott

  reply	other threads:[~2007-10-15 19:32 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 [this message]
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
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=4713BE5E.3030406@freescale.com \
    --to=scottwood@freescale.com \
    --cc=grant.likely@secretlab.ca \
    --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.