From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command
Date: Wed, 09 Jul 2008 13:02:33 -0400 [thread overview]
Message-ID: <4874EF29.3000102@ge.com> (raw)
In-Reply-To: <FC2F8079-75AE-4DCE-801A-7CE8F2EF7FBA@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jul 9, 2008, at 10:17 AM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> If the path we are trying to print doesn't exist see if it matches an
>>> aliases. We don't do anything fancy at this point, but just strip the
>>> leading '/' if it exists and see if we have an exact match to an alias.
>>> In the future we could try and prefix matching so the alias could be
>>> used
>>> as a shorter path reference.
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> Cool and useful too. Out of curiousity, does "real" Open Firmware do
>> this sort of thing with aliases?
>
> I'm pretty sure it the Apple OF implementation does. However I dont
> remember to what extent it does from my playing around with OF on Apple HW.
Sounds like I'm going to have to preempt my kids on the olpc and see
what OF does on it. :-)
>> One reservation I have (which may disappear if the answer to the
>> previous question is "yes"), it automatically and silently
>> dereferences the /aliases/X node when asked to display /X or X (but
>> only if /X doesn't exist in the dtb). This is not an obvious behavior
>> since X isn't real.
>
> we could print out something about using an alias so the user knows that
> its happening.
>
>> Should we have a different display syntax to force the dereference of
>> an alias X? Assuming "*" is a good choice, this would change the
>> behavior
>> fdt print *ethernet0
>> to dereference /aliases/ethernet0 and print out
>> /soc8360 at e0000000/.../enet0 (or whatever).
>
> Lets says I have an alias for 'soc' to 'soc8360 at e000000'. I want to be
> able to in the future do print /soc/enet0 and have that work.
> Introducing some new syntax would make that difficult and more ugly.
>
> - k
Thinking out loud... we could define the syntax that a leading "*"
indicates the first part of the path is a dereference of /aliases.
Assuming
/aliases/soc = /soc8360 at e000000
/aliases/ethernet0 = /soc8360 at e0000000/.../enet0
then
print *soc/enet0
and
print *ethernet0
would both work and print the right thing. You *would* have to know
that the first element of the path is an /aliases dereference. Your
original patch did not require that piece of knowledge (but silently and
automagically, which makes me nervous).
gvb
next prev parent reply other threads:[~2008-07-09 17:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 14:40 [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command Kumar Gala
2008-07-09 15:17 ` Jerry Van Baren
2008-07-09 16:51 ` Kumar Gala
2008-07-09 17:02 ` Jerry Van Baren [this message]
2008-08-01 14:08 ` Kumar Gala
2008-08-03 0:51 ` Jerry Van Baren
2008-08-04 1:10 ` David Gibson
2008-08-04 1:24 ` Jerry Van Baren
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=4874EF29.3000102@ge.com \
--to=gerald.vanbaren@ge.com \
--cc=u-boot@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox