From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Date: Fri, 12 Oct 2007 14:28:11 +1000 Subject: [U-Boot-Users] libfdt release? In-Reply-To: <470EB351.4070009@gmail.com> References: <006E3CAD-11CB-4892-8BDB-9866677F371D@freescale.com> <20071010061458.GA6135@localhost.localdomain> <912BB32E-FD7D-4CBC-AE3D-3D358E97DECB@freescale.com> <20071011041239.GF14873@localhost.localdomain> <9917D225-2082-4900-BFD4-96490EA88C42@freescale.com> <470EB351.4070009@gmail.com> Message-ID: <20071012042811.GK21056@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Oct 11, 2007 at 07:35:45PM -0400, Jerry Van Baren wrote: [snip] > >>>* Replace fdt_node_offset() with fdt_find_node_by_path(). > >> > >>There is no fdt_node_offset(), fdt_path_offset() they mean, maybe. > >>And why a gratuitous name change...? > > > >Jerry? > > We needed the function (Detlev, IIRC). The gratuitous name change was > intended to be more descriptive. Perhaps if the correct original name > were used, we wouldn't have needed a gratuitous name change. ;-) Heh. Do bear in mind in future that the naming conventions in libfdt aren't arbitrary. I've tried to put "offset" in the name of everything that returns a structure block offset as a hint to that return convention. Additionally it's supposed to mitigate the big libfdt gotcha - that offsets aren't handles, so the offset for a node can change if you alter another node. > >>>* Add some utilities to manipulate the reserved memory map. (think > >>>your recent patch my cover that) > >> > >>Should do. > >> > >>>* libfdt: Make fdt_check_header() public > >> > >>Hrm. Why? > > > >Jerry? > > Because we needed to check the validity of the header outside of libfdt > and decide whether we wanted to use the blob or not. That seems reasonable. I'll look at exporting that. Although.. I'm a little surprised that u-boot doesn't just to an fdt_open_into() as the first thing, which would include the check. > >>>* libfdt: Enhanced and published fdt_next_tag() > >> > >>Hrm. I'm not categorically opposed to publishing fdt_next_tag(), but > >>I'm disinclined to do so without good reason. > > > >Jerry? > > > >Hopefully Jerry will comment on why the additions were made to u-boot. > > I needed it to implement my u-boot "fdt print" command, to step through > the tags so I could print them out in a human readable format (it > actually is dtc-input-compatible and, in most cases, matches the > original dtc input source code). Hrm, I see. For debugging purposes, essentially. I have been thinking for some time that I needed to add user-accesible traversal functions - I just haven't managed to come up with an interface I like, yet. > >David, one thing that would be extremely useful is "API" comments in > >libfdt.h for each of the functions. > > Add my vote too. ;-) Yeah, I know... -- 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