devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: device-tree
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	linux-omap <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Tarun Kanti DebBarma <tarun.kanti-l0cyMroinI0@public.gmane.org>,
	linux-arm
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: Mis?use of aliases
Date: Sat, 14 Jul 2012 07:07:17 -1000	[thread overview]
Message-ID: <5001A745.3000509@firmworks.com> (raw)
In-Reply-To: <20120714163701.GI11326-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>

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.

> 
> 	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".

For historical reference: The original use of /aliases was as a
component of pathname resolution, which is a "global" function.  In that
usage model, a given alias does not necessarily refer specifically to
exactly one node, so "localizing" an alias inside a node doesn't work.

The new usage for binding to a Linux name could be localized.  My
general preference is to localize whenever possible.  But, again,
breaking that rule in this case is not a huge problem.

Thanks again for zeroing in on my mistake.

Mitch

  parent reply	other threads:[~2012-07-14 17:07 UTC|newest]

Thread overview: 33+ 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
     [not found]     ` <5000D647.4090200-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-14  5:30       ` Mis?use of aliases Mitch Bradley
     [not found]         ` <50010402.3050502-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-14 16:37           ` David Gibson
     [not found]             ` <20120714163701.GI11326-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2012-07-14 17:07               ` Mitch Bradley [this message]
     [not found]                 ` <5001A745.3000509-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-15  7:39                   ` David Gibson
2012-07-14  6:56       ` [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes Paul Walmsley
2012-07-14 14:01         ` Rob Herring
     [not found]           ` <50017BB1.8010702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-14 17:42             ` Paul Walmsley
2012-07-16 17:48               ` Paul Walmsley
2012-07-16 15:56     ` 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
     [not found]           ` <5048A8F6.6080108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
     [not found]       ` <502D2686.4090107-l0cyMroinI0@public.gmane.org>
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
     [not found]     ` <alpine.DEB.2.00.1207131740460.25585-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
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=5001A745.3000509@firmworks.com \
    --to=wmb-d5eqfidgl7eakbo8gow8eq@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tarun.kanti-l0cyMroinI0@public.gmane.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).