From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 11 Oct 2007 19:35:45 -0400 Subject: [U-Boot-Users] libfdt release? In-Reply-To: <9917D225-2082-4900-BFD4-96490EA88C42@freescale.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> Message-ID: <470EB351.4070009@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 Kumar Gala wrote: >>> Yeah I was going through the u-boot mods and noticed a few additions. >>> >>> Pulled from the u-boot git commit logs: >>> >>> * add convenience function fdt_find_and_setprop() >> >> I don't think this belongs in libfdt itself - in the bootwrapper we'd >> do this in devtree.c. u-boot can keep it's function outside of >> libfdt. > > Agreed, I think u-boot should remove this in the future as the one user > should move to a more generic mechanism for handling "fixups". Makes sense. NBD. >>> * Add fdt_find_node_by_type() and fdt_find_compatible_node() to LIBFDT >> >> fdt_find_node_by_type() should be subsumed by >> fdt_node_offset_by_prop_value() which we already have upstream. I'm >> working on a fdt_node_offset_by_compatible(). OK. >>> * 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. ;-) >>> * 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. >>> * 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). > David, one thing that would be extremely useful is "API" comments in > libfdt.h for each of the functions. Add my vote too. ;-) > - k HTH, gvb