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