From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Date: Tue, 16 Oct 2007 09:03:32 +0200 Subject: [U-Boot-Users] libfdt release? In-Reply-To: <20071016024419.GL26787@localhost.localdomain> References: <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> <20071012042811.GK21056@localhost.localdomain> <470F6164.6010601@smiths-aerospace.com> <20071015041239.GJ14108@localhost.localdomain> <477B32C9-EC0F-4DB7-A1A1-C5E3041C9CDE@freescale.com> <4713BDD2.7070608@grandegger.com> <20071016024419.GL26787@localhost.localdomain> Message-ID: <47146244.2020302@grandegger.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 Mon, Oct 15, 2007 at 09:21:54PM +0200, Wolfgang Grandegger wrote: >> Kumar Gala wrote: >>> Guys, >>> >>> Can you tell me where we stand on changes/additions to libfdt vs u- >>> boot. I'd really like to see an updated libfdt imported into u-boot >>> for the next window and am happy to work on the u-boot modifications >>> as long as I understand what exactly they are. >>> >>> Having fdt_get_name() and fdt_get_path() will be really useful for >>> some fixup of device node code I've got and will allow us to drop the >>> hard coded/explicit PATHs to nodes from . >>> >>> I'd rather see us take a clean libfdt drop rather than pulling in >>> bits and pieces. >> Yes, that would be nice but the libfdt for U-Boot may still need to be >> extended, especially for dynamic configuration. Therefore I would >> appreciate a discussion on what else we need for that purpose and how we >> handle (separate) common and extended libfdt functions for U-Boot. For > > Again, I'm happy to add functionality to core libfdt if u-boot needs > it (as long as it isn't fundamentally u-boot specific, of course). The functions below are not really U-Boot specific. >> the dynamic configuration, I'm clearly in favor of function names >> similar to the one commonly used in Linux (with the prefix fdt:): >> >> of_find_node_by_path >> of_find_node_by_type >> of_find_node_by_phandle >> of_find_compatible_node >> of_device_is_compatible >> of_get_property > > Tough. The names I have are staying for the reasons I've already > mentioned. And because I want to keep the libfdt API reasonably > stable. OK, just my personal opinion on gratuitous name changes. What functions are missing in the libfdt? How can I help to get them ported to the generic libfdt? Wolfgang.