[U-Boot-Users] libfdt release?

[Jerry Van Baren]

Kumar Gala wrote:
>>> Yeah I was going through the u-boot mods and noticed a few additions.
>>>
>>> Pulled from the u-boot git commit logs:
>>>
>>> * add convenience function fdt_find_and_setprop()
>>
>> I don't think this belongs in libfdt itself - in the bootwrapper we'd
>> do this in devtree.c.  u-boot can keep it's function outside of
>> libfdt.
> 
> Agreed, I think u-boot should remove this in the future as the one user 
> should move to a more generic mechanism for handling "fixups".

Makes sense.  NBD.

>>> * Add fdt_find_node_by_type() and fdt_find_compatible_node() to LIBFDT
>>
>> fdt_find_node_by_type() should be subsumed by
>> fdt_node_offset_by_prop_value() which we already have upstream.  I'm
>> working on a fdt_node_offset_by_compatible().

OK.

>>> * Replace fdt_node_offset() with fdt_find_node_by_path().
>>
>> There is no fdt_node_offset(), fdt_path_offset() they mean, maybe.
>> And why a gratuitous name change...?
> 
> Jerry?

We needed the function (Detlev, IIRC).  The gratuitous name change was 
intended to be more descriptive.  Perhaps if the correct original name 
were used, we wouldn't have needed a gratuitous name change. ;-)

>>> * Add some utilities to manipulate the reserved memory map. (think
>>> your recent patch my cover that)
>>
>> Should do.
>>
>>> * libfdt: Make fdt_check_header() public
>>
>> Hrm.  Why?
> 
> Jerry?

Because we needed to check the validity of the header outside of libfdt 
and decide whether we wanted to use the blob or not.

>>> * libfdt: Enhanced and published fdt_next_tag()
>>
>> Hrm.  I'm not categorically opposed to publishing fdt_next_tag(), but
>> I'm disinclined to do so without good reason.
> 
> Jerry?
> 
> Hopefully Jerry will comment on why the additions were made to u-boot.

I needed it to implement my u-boot "fdt print" command, to step through 
the tags so I could print them out in a human readable format (it 
actually is dtc-input-compatible and, in most cases, matches the 
original dtc input source code).

> David, one thing that would be extremely useful is "API" comments in 
> libfdt.h for each of the functions.

Add my vote too. ;-)

> - k

HTH,
gvb