On Wed, Jul 15, 2015 at 03:45:07PM -0600, Simon Glass wrote: > Hi Jon, > > On 15 July 2015 at 07:29, Jon Loeliger <j...@jdl.com> wrote: > > > > So, like, Thierry Reding said: > > > From: Thierry Reding <tred...@nvidia.com> > > > > > > These three patches add a couple of string functions that have proven > > > useful in U-Boot's copy of libfdt, so they are likely to be useful for > > > other users as well. > > > > > > Patch 1 adds a function to count the number of strings in a property's > > > value. This also adds a new DTS sample along with a small test program > > > to validate the implemented functions. > > > > > > Patch 2 adds a function to retrieve the index of a given string in any > > > given property's value. This adds code to the test program introduced in > > > the previous patch to exercise the new functionality. > > > > > > Patch 3 adds a function to retrieve a string by index from a property's > > > value along with a shortcut for index 0. This extends the test program > > > introduced in patch 1 to validate the new functionality. > > > > > > Thierry > > > > > > Hi Thierry, > > > > While I am generally fine with this patch set, I have > > a large-scope question. Is there a larger plan to > > consolidate or unify the U-Boot and DTC libfdts? > > I maintain the fdt tree for U-Boot at present. About once a quarter I > check what has changed and do a bit of a sync. But there are things > that libfdt upstream has not accepted - e.g. the grep functionality > used by verified boot hashing stuff. I wish we could figure that out. > Perhaps a cut-down fdtgrep tool would meet with favour. We're using it > even more now since SPL (the minimal U-Boot loader) wants to run with > a subset of the full board FDT for SRAM space reasons.
So, short-term: there's no reason your fdtgrep stuff needs to be
considered as part of your version of libfdt - it could just as easily
be an add-on sitting alongside libfdt - then you could share the core
libfdt code at least.
Longer term, my main sticking point on the fdtgrep stuff was entry
points whose semantics don't make me go cross-eyed (includes these
nodes, but not those nodes, and might include children if this flag is
set, but not that one and the operator's shoe size matches some other
property...). I'm not sure if that's a question of redesigning the
interface, or just of describing it better.
> I do ask people to send things upstream, and if rejected we then have
> to work out what to do...there are recent U-Boot mailing list threads
> on this.
>
> Regards,
> Simon
--
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
pgp81OW7YdsR_.pgp
Description: PGP signature
