devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Gaurav Minocha
	<gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Rob Herring <rob.herring-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH] Patch to improve device tree structure
Date: Wed, 03 Dec 2014 11:42:57 -0800	[thread overview]
Message-ID: <547F67C1.2060605@gmail.com> (raw)
In-Reply-To: <CACxGe6v-=nWamWbbe0EBk_X5D1M3LSo_CZ_w95NSVS5jcio=NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 12/3/2014 7:09 AM, Grant Likely wrote:
> On Wed, Dec 3, 2014 at 3:39 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 11/28/2014 8:48 AM, Grant Likely wrote:

< snip >

>>> Instead of keeping it always in order, what about reordering the whole
>>> list after all the nodes at a given level are unflattened? That would
>>> avoid traversing the entire sibling list on every node addition. Like
>>> this:
>>
>> Seems pretty close to a wash to me.  Either one would work.  Though
>> mine would benefit from the comment you added in yours.
>>
>> -Frank
> 
> Okay, if I can take that as an 'acked-by' from you then I'll merge my
> version of the patch. I prefer doing the post processing to sort the
> list because it is theoretically less costly.

Yes, that would be fine.

Acked-by:  Frank Rowand <frank.rowand-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>

> 
> g.
> 
>>>
>>> g.
>>>
>>> >From de46de766eb4d2240208bf83fdae955361069352 Mon Sep 17 00:00:00 2001
>>> From: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Date: Fri, 28 Nov 2014 16:03:33 +0000
>>> Subject: [PATCH] of: Drop ->next pointer from struct device_node
>>>
>>> The ->next pointer in struct device_node is a hanger-on from when it was
>>> used to iterate over the whole tree by a particular device_type property
>>> value. Those days are long over, but the fdt unflattening code still
>>> uses it to put nodes in the unflattened tree into the same order as node
>>> in the flat tree. By reworking the unflattening code to reverse the list
>>> after unflattening all the children of a node, the pointer can be
>>> dropped which gives a small amount of memory savings.
>>>
>>> Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Cc: Gaurav Minocha <gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>>  drivers/of/fdt.c   | 24 ++++++++++++++++++------
>>>  include/linux/of.h |  1 -
>>>  2 files changed, 18 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>> index 7f6ee31d5650..a41f9fdb1aa0 100644
>>> --- a/drivers/of/fdt.c
>>> +++ b/drivers/of/fdt.c
>>> @@ -226,12 +226,8 @@ static void * unflatten_dt_node(void *blob,
>>>               prev_pp = &np->properties;
>>>               if (dad != NULL) {
>>>                       np->parent = dad;
>>> -                     /* we temporarily use the next field as `last_child'*/
>>> -                     if (dad->next == NULL)
>>> -                             dad->child = np;
>>> -                     else
>>> -                             dad->next->sibling = np;
>>> -                     dad->next = np;
>>> +                     np->sibling = dad->child;
>>> +                     dad->child = np;
>>>               }
>>>       }
>>>       /* process properties */
>>> @@ -329,6 +325,22 @@ static void * unflatten_dt_node(void *blob,
>>>
>>>       if (*poffset < 0 && *poffset != -FDT_ERR_NOTFOUND)
>>>               pr_err("unflatten: error %d processing FDT\n", *poffset);
>>> +
>>> +     /*
>>> +      * Reverse the child list. Some drivers assumes node order matches .dts
>>> +      * node order
>>> +      */
>>> +     if (!dryrun && np->child) {
>>> +             struct device_node *child = np->child;
>>> +             np->child = NULL;
>>> +             while (child) {
>>> +                     struct device_node *next = child->sibling;
>>> +                     child->sibling = np->child;
>>> +                     np->child = child;
>>> +                     child = next;
>>> +             }
>>> +     }
>>> +
>>>       if (nodepp)
>>>               *nodepp = np;
>>>
>>> diff --git a/include/linux/of.h b/include/linux/of.h
>>> index 8b021db3e16e..3f0f0ffbd5e5 100644
>>> --- a/include/linux/of.h
>>> +++ b/include/linux/of.h
>>> @@ -56,7 +56,6 @@ struct device_node {
>>>       struct  device_node *parent;
>>>       struct  device_node *child;
>>>       struct  device_node *sibling;
>>> -     struct  device_node *next;      /* next device of same type */
>>>       struct  kobject kobj;
>>>       unsigned long _flags;
>>>       void    *data;
>>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-12-03 19:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17  4:52 [PATCH] Patch to improve device tree structure Gaurav Minocha
     [not found] ` <1416199976-21147-1-git-send-email-gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-18  1:57   ` Frank Rowand
2014-11-18 15:10   ` Grant Likely
     [not found]     ` <20141118151026.D2D63C40966-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-11-19  1:37       ` Frank Rowand
     [not found]         ` <546BF447.6080300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-19 13:56           ` Grant Likely
     [not found]             ` <CACxGe6u1YwQAivktwmiOZx1K1Ch0F1ofx3EriBi1qEAU99X9PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-19 19:30               ` Frank Rowand
     [not found]                 ` <546CEFC4.805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-19 20:03                   ` Frank Rowand
     [not found]                     ` <546CF7AD.8060707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-19 20:05                       ` Frank Rowand
2014-11-28 16:48                   ` Grant Likely
     [not found]                     ` <20141128164829.CC876C40884-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-12-03  3:39                       ` Frank Rowand
     [not found]                         ` <547E85DF.5000200-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-03 15:09                           ` Grant Likely
     [not found]                             ` <CACxGe6v-=nWamWbbe0EBk_X5D1M3LSo_CZ_w95NSVS5jcio=NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-03 19:42                               ` Frank Rowand [this message]
2014-11-24  1:22       ` Gaurav Minocha
     [not found]         ` <CA+rpMbKZvMb4uxSFabvXG5nRNQnNXnAKUhdjn0Vp_wZBFN8COw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-28  3:59           ` Gaurav Minocha
2014-11-28 15:46           ` Grant Likely

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=547F67C1.2060605@gmail.com \
    --to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=rob.herring-QSEj5FYQhm4dnm+yROfE0A@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).