From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Sun, 03 Aug 2008 21:24:40 -0400 Subject: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command In-Reply-To: <20080804011038.GD775@yookeroo.seuss> References: <4874D673.1090606@ge.com> <4874EF29.3000102@ge.com> <4895012A.90907@gmail.com> <20080804011038.GD775@yookeroo.seuss> Message-ID: <48965A58.30807@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de David Gibson wrote: > On Sat, Aug 02, 2008 at 08:51:54PM -0400, Jerry Van Baren wrote: [snip] >> I've CC:ed David Gibson in case he has some advice - the concept is to >> indicate a dereference of /aliases nodes so that us lazy engineers don't >> have to cut'n'paste the whole long path from the alias. Kumar >> originally proposed to do it automagically and I countered proposing >> using "*" to indicate the next path name should be looked up in /aliases >> and the result used instead (i.e. dereferenced). Discussion thread: >> > > No, I really don't think using this "dereference" character is a good > idea. If you're going to expand aliases, you should do it as real OF > does - see section 4.3 of IEEE1275. Essentially it's the *lack* of a > leading '/' character that triggers alias expansion. So you could use > e.g. > /soc8360 at e0000000/ethernet at e0000400 > or > soc/ethernet at e0000400 > or > ethernet0 Ahh, I didn't read far enough. The algorithm in section 4.3 is much better thought out than either of our proposals. [snip] > If you're interepreting them in one place, you should probably > interpret them everywhwere and have a single "resolve pathname" > function. Yes. > In fact, I should quite possibly put such a function into libfdt. That would be very useful. :-) Thanks, gvb