[PATCH] dtc: fix for_each_*() to skip first object if deleted

[Stephen Warren]

On 10/03/2012 05:42 PM, Rob Herring wrote:
> On 10/03/2012 05:32 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> The previous definition of e.g. for_each_*() would always include the
>> very first object within the list of processed labels, irrespective of
>> whether it was marked deleted, since the deleted flag was not checked
>> on the first object, but only on any "next" object.
>>
>> Fix for_each_*() to call skip_deleted_*() prior to every loop iteration,
>> including the first, i.e. as part of the for loop test expression rather
>> than as part of the increment statement, to correct this.
>>
>> Incidentally, this change is why commit 45013d8 dtc: "Add ability to
>> delete nodes and properties" only caused two "make checkm" failures;
>> only two tests actually use multiple labels on the same property or
>> node. With this current change applied, but commit 317a5d9 "dtc: zero
>> out new label objects" reverted, "make checkm" fails 29 times; i.e.
>> for every test that uses any labels at all.
>>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> ---
>> Rob, Grant, now that you're listed as maintainers for the Linux kernel's
>> copy of dtc, will you automatically apply patches there as they are
>> accepted into upstream dtc, or should I still create "backport" patches
>> and send them to you separately?
> 
> I guess the fundamental question is when do we sync upstream dtc:
...
> Assuming we go with pick-up all the dtc changes every kernel cycle, it
> should be simple enough to script picking up commits from upstream. I'm
> assuming it is just a path fix-up? In that case, it wouldn't be
> necessary to post both versions of patches. Now, if someone wants to do
> that script and just provide me a git branch to pull, I would be more
> than happy to take it.

There are a couple of things that make scripting this slightly non-trivial:

a) The kernel has its own Makefile, so when Makefile.dtc is changed, the
kernel's Makefile needs equivalent changes.

I guess a script could just check for Makefile edits, and flag the
commit as needing manual fixup later or something.

b) The kernel doesn't run flex/bison, but rather relies on having
checked-in copies of their output with "_shipped" names.

I guess this wouldn't be too hard to automate.

c) And of course, some files don't get checked into the kernel (e.g.
tests/), but that and the path change should be easy to handle.