Hi David, On 16 July 2015 at 17:40, David Gibson <da...@gibson.dropbear.id.au> wrote: > On Thu, Jul 16, 2015 at 10:56:23AM -0600, Simon Glass wrote: >> Hi David, >> >> On 15 July 2015 at 23:27, David Gibson <da...@gibson.dropbear.id.au> 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 <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. >> >> 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. > > It's not really the fdtgrep tool which bothers me, I'm much more > concerned with the semantics of the libfdt function it uses to do its > work.
Yes that's the tricky bit. I'll revisit it again with fresh eyes (it has been a while) and see if there is something I can do. Fundamentally it is not complex, but there are quite a few combinations to deal with and I think that is the tricky part. > >> >> 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 >> > >> >> Regards, >> Simon Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
