From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Date: Tue, 16 Oct 2007 12:44:19 +1000 Subject: [U-Boot-Users] libfdt release? In-Reply-To: <4713BDD2.7070608@grandegger.com> 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> Message-ID: <20071016024419.GL26787@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 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 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. -- 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