Hi David, On 15 July 2015 at 23:27, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Jul 15, 2015 at 03:45:07PM -0600, Simon Glass wrote: >> Hi Jon, >> >> On 15 July 2015 at 07:29, Jon Loeliger <jdl@xxxxxxx> wrote: >> > >> > So, like, Thierry Reding said: >> > > From: Thierry Reding <treding@xxxxxxxxxx> >> > > >> > > 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. That's how it is today, yes. > > 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. Neither am I, but perhaps if I cut down the fdtgrep options so that it only does a few basic things that would help? The full feature set would still be in the implementation, but it would reduce confusion on that side. > >> 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 Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
