From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Date: Mon, 15 Oct 2007 21:21:54 +0200 Subject: [U-Boot-Users] libfdt release? In-Reply-To: <477B32C9-EC0F-4DB7-A1A1-C5E3041C9CDE@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> <470EB351.4070009@gmail.com> <20071012042811.GK21056@localhost.localdomain> <470F6164.6010601@smiths-aerospace.com> <20071015041239.GJ14108@localhost.localdomain> <477B32C9-EC0F-4DB7-A1A1-C5E3041C9CDE@freescale.com> Message-ID: <4713BDD2.7070608@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 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 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 Wolfgang.