From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH] dtc: fix for_each_*() to skip first object if deleted
Date: Wed, 03 Oct 2012 18:42:32 -0500 [thread overview]
Message-ID: <506CCD68.4030000@gmail.com> (raw)
In-Reply-To: <1349303574-4635-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 10/03/2012 05:32 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> 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: in
sync with the kernel cycles or based on some upstream dtc milestone?
There's not really releases of dtc unless you go ask for one. So I don't
think any particular commit is more or less stable. I would guess most
users are using the in kernel version, so upstream is probably not
getting tested enough that we would gain some test coverage by waiting.
This was my rational for picking up the changes for 3.7.
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.
Rob
>
> dtc.h | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/dtc.h b/dtc.h
> index d501c86..88da264 100644
> --- a/dtc.h
> +++ b/dtc.h
> @@ -161,47 +161,46 @@ struct node {
> struct label *labels;
> };
>
> -static inline struct label *for_each_label_next(struct label *l)
> +static inline struct label *skip_deleted_labels(struct label *l)
> {
> - do {
> + while (l && l->deleted)
> l = l->next;
> - } while (l && l->deleted);
>
> return l;
> }
>
> #define for_each_label(l0, l) \
> - for ((l) = (l0); (l); (l) = for_each_label_next(l))
> + for ((l) = (l0); ((l) = skip_deleted_labels(l)); (l) = (l)->next)
>
> #define for_each_label_withdel(l0, l) \
> for ((l) = (l0); (l); (l) = (l)->next)
>
> -static inline struct property *for_each_property_next(struct property *p)
> +static inline struct property *skip_deleted_properties(struct property *p)
> {
> - do {
> + while (p && p->deleted)
> p = p->next;
> - } while (p && p->deleted);
>
> return p;
> }
>
> #define for_each_property(n, p) \
> - for ((p) = (n)->proplist; (p); (p) = for_each_property_next(p))
> + for ((p) = (n)->proplist; ((p) = skip_deleted_properties(p)); \
> + (p) = (p)->next)
>
> #define for_each_property_withdel(n, p) \
> for ((p) = (n)->proplist; (p); (p) = (p)->next)
>
> -static inline struct node *for_each_child_next(struct node *c)
> +static inline struct node *skip_deleted_children(struct node *c)
> {
> - do {
> + while (c && c->deleted)
> c = c->next_sibling;
> - } while (c && c->deleted);
>
> return c;
> }
>
> #define for_each_child(n, c) \
> - for ((c) = (n)->children; (c); (c) = for_each_child_next(c))
> + for ((c) = (n)->children; ((c) = skip_deleted_children(c)); \
> + (c) = (c)->next_sibling)
>
> #define for_each_child_withdel(n, c) \
> for ((c) = (n)->children; (c); (c) = (c)->next_sibling)
>
next prev parent reply other threads:[~2012-10-03 23:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 22:32 [PATCH] dtc: fix for_each_*() to skip first object if deleted Stephen Warren
[not found] ` <1349303574-4635-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-03 23:42 ` Rob Herring [this message]
[not found] ` <506CCD68.4030000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-04 18:05 ` Stephen Warren
2012-10-04 5:00 ` David Gibson
-- strict thread matches above, loose matches on Subject: below --
2012-10-08 22:15 Stephen Warren
[not found] ` <1349734526-29792-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-09 3:13 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506CCD68.4030000@gmail.com \
--to=robherring2-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).