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:54:39 -0500 [thread overview]
Message-ID: <4713C57F.7060509@freescale.com> (raw)
In-Reply-To: <fa686aa40710151248y5e921a4fmbb0a3e0b7c9a2ca5@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
>> 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.
>
> Here the corresponding problem; having to scan every device node to
> make sure you don't assign a number already selected by another node
> (in the case where one node is assigned a number and another is not).
>
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.
>>> 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. :-)
>
> Not really; if the user needs to renumber devices; you don't want him
> fiddling around in the hardware description.
Why would the user renumber devices?
> Just like the chosen node; an aliases describes logical constructs,
> not physical ones. I don't think this is any different from the
> linux,stdout-path property in chosen.
Well, it's somewhat different in that stdout describes a usage of the
device, not the identity.
Still, I don't like linux,stdout-path. :-)
At the very least it should be a phandle.
-Scott
next prev parent reply other threads:[~2007-10-15 20:03 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 [this message]
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=4713C57F.7060509@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.