From: david@gibson.dropbear.id.au (David Gibson)
To: linux-arm-kernel@lists.infradead.org
Subject: Mis?use of aliases
Date: Sun, 15 Jul 2012 17:39:19 +1000 [thread overview]
Message-ID: <20120715073919.GJ11326@truffala.fritz.box> (raw)
In-Reply-To: <5001A745.3000509@firmworks.com>
On Sat, Jul 14, 2012 at 07:07:17AM -1000, Mitch Bradley wrote:
> On 7/14/2012 6:37 AM, David Gibson wrote:
> > On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote:
> >>> I'm not sure this is really a good use of aliases. UARTs use aliases
> >>> because it is important that the UART number to tty number is known and
> >>> fixed.
> >>
> >> This brings up an issue that I've been meaning to comment on.
> >>
> >> The use of phandle-valued properties in the aliases node causes real OFW
> >> implementations some amount of heartburn. The Open Firmware standard
> >> says that the properties in /aliases are string-valued. That's
> >> important, because aliases are shorthand for fragments of full device
> >> specifiers (pathnames that can include arguments to nodes). Phandles
> >> can point to nodes, but can't be relative, and can't encode
> >> per-node-component arguments.
> >
> > Um, so, properties in /aliases should not have phandle values, flat
> > tree or otherwise. Has this been seen in the wild, or are you being
> > misled by the fact that dtc's reference-to-phandle and
> > reference-to-path syntax is very similar:
>
> Yes, I was indeed being misled. Thanks for the clarification. The
> "&fred" syntax is present in the .dts files that I have looked at.
Right, it's all about the context. &label is always a reference to
another node, but in cell context < ... > that's expanded as a
phandle, in bare context it's expanded as a path.
> > prop = <&fred>;
> > Will generate a phandle valued property, but
> > prop = &fred;
> > Will generate a string (path) valued property.
> >
> >> For binding a Linux unit number to a device node, I would prefer to
> >> decorate the node with a property like "linux,unit#", instead of
> >> breaking the standard semantics of /aliases.
> >
> > I don't see how using aliases for unit numbering (inherently) breaks
> > the semantics of /aliases. If phandle valued properties are being
> > used that is wrong, but it's not necessary for the unit numbering
> > anyway.
>
> I agree, the use of string-valued /aliases is not a semantic problem.
> That said, I still think that decorating individual nodes is a better
> approach, for locality reasons. But, now that my misunderstanding has
> been cleared up, it's a mild preference instead of "heartburn".
So, I think aliases was suggested for this sort of numbering precisely
because it _isn't_ local. Particularly when numbering similar devices
across unrelated busses, the ordering more or less has to be a global
platform convention, and may not be derived from - or even contradict
- local numbering conventions from individual busses or components.
--
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:[~2012-07-15 7:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 22:26 [RFC RESEND 0/4] ARM: OMAP3+: Add device-tree support for timers Jon Hunter
2012-07-13 22:26 ` [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes Jon Hunter
2012-07-14 2:15 ` Rob Herring
2012-07-14 6:56 ` Paul Walmsley
2012-07-14 14:01 ` Rob Herring
2012-07-14 17:42 ` Paul Walmsley
2012-07-16 17:48 ` Paul Walmsley
[not found] ` <50010402.3050502@firmworks.com>
2012-07-14 16:37 ` Mis?use of aliases David Gibson
2012-07-14 17:07 ` Mitch Bradley
2012-07-15 7:39 ` David Gibson [this message]
2012-07-16 15:56 ` [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes Jon Hunter
2012-07-18 7:19 ` Tony Lindgren
2012-07-18 15:11 ` Jon Hunter
2012-07-23 15:24 ` Jon Hunter
2012-08-15 9:11 ` Vaibhav Hiremath
2012-08-16 15:04 ` Jon Hunter
2012-08-30 20:14 ` Tony Lindgren
2012-09-07 20:26 ` Jon Hunter
2012-09-07 20:56 ` Tony Lindgren
2012-09-07 21:16 ` Jon Hunter
2012-09-06 13:45 ` Rob Herring
2012-09-07 2:09 ` Jon Hunter
2012-07-13 22:26 ` [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices Jon Hunter
2012-08-15 9:13 ` Vaibhav Hiremath
2012-08-16 16:57 ` Jon Hunter
2012-08-17 5:32 ` Hiremath, Vaibhav
2012-08-17 12:24 ` Jon Hunter
2012-08-24 15:56 ` Hiremath, Vaibhav
2012-07-13 22:26 ` [RFC RESEND 3/4] ARM: OMAP4: Add timer clock aliases for device-tree Jon Hunter
2012-07-13 22:26 ` [RFC RESEND 4/4] ARM: OMAP: Add DT support for timer driver Jon Hunter
2012-07-13 23:41 ` Paul Walmsley
2012-07-14 0:57 ` Jon Hunter
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=20120715073919.GJ11326@truffala.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).