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

On 10/03/2012 05:42 PM, Rob Herring wrote:

On 10/03/2012 05:32 PM, Stephen Warren wrote:

quoted

From: Stephen Warren <redacted>

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 <redacted>
---
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.