[U-Boot-Users] libfdt release?

David Gibson david at gibson.dropbear.id.au
Tue Oct 16 09:19:19 CEST 2007


On Tue, Oct 16, 2007 at 09:03:32AM +0200, Wolfgang Grandegger wrote:
> 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 <config.h>.
> >>>
> >>>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.

Sure, and we have nearly all of them.

> >>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?

There are functions for all of these, either already in libfdt, or
included in a patch I sent to jdl today.

 * of_find_node_by_path => fdt_path_offset()

 * of_find_node_by_type => fdt_node_offset_by_prop_value() 
 * of_find_node_by_phandle => fdt_node_offset_by_prop_value()

Although I suspect the only reason u-boot needs the first of these is
because of the broken early Freescale bindings which use device_type
in ways they shouldn't.

 * of_find_compatible_node => fdt_node_offset_by_compatible()
 * of_device_is_compatible => fdt_node_check_compatible()

Both in today's patch to jdl.  Beware that fdt_node_check_compatible()
has reversed sense from of_device_is_compatible() (returns 0 if the
node *is* compatible).  That's so it can return error codes in the
normal way if passed a junk tree or offset.

-- 
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




More information about the U-Boot mailing list