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 15:45:04 -0500 [thread overview]
Message-ID: <4713D150.2020806@freescale.com> (raw)
In-Reply-To: <fa686aa40710151326m789046aaq60ba002e180d4e14@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
>> Don't Do That(tm). If you use this mechanism, and an adapter node
>> doesn't have a bus number, then it doesn't get to pre-register devices,
>> but instead must use i2c_new_device.
>
> Even that doesn't work. For example if a PCI device is probed which
> registers an i2c bus; there needs to be a mechanism for the i2c layer
> to know that an id is already spoken for, so once again there needs to
> be a mechanism to map easily from id to device (or lack thereof).
As long as all statically-assigned buses have their devices passed to
i2c_register_board_info by platform code before the PCI device is
probed, the i2c layer will hand out bus numbers that don't conflict.
> Where user == system integrator or firmware engineer. ie. boards with
> no-populate options which affect the numbering; changes to match the
> silkscreening on the chassis when a common board is used by multiple
> systems. It's a conceivable scenario. (Again; this is more relevant
> to eth and serial devices than i2c).
Sure, but I guess I don't see the problem with such a person editing the
label property. The label property also gives more freedom in terms of
which characters can be used in the description.
Aliases could still be used when there's a higher level abstraction
related to purpose, not identification.
-Scott
next prev parent reply other threads:[~2007-10-15 20:53 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 [this message]
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=4713D150.2020806@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.