From: Andres Salomon <dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Daniel Drake <dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC 2/3] OLPC: add missing elements to device tree
Date: Wed, 9 Mar 2011 18:51:25 -0800 [thread overview]
Message-ID: <20110309185125.0ca53221@queued.net> (raw)
In-Reply-To: <20110306001943.GB7467-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
On Sat, 5 Mar 2011 17:19:43 -0700
Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> On Sat, Mar 05, 2011 at 09:23:47AM -0800, Andres Salomon wrote:
> > On Fri, 4 Mar 2011 21:50:42 -0700
> > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> >
> > > > +static void __init prom_alloc_property(struct device_node
> > > > *node,
> > > > + const char *name, const char *value)
> > > > +{
> > > > + struct property *p = prom_early_alloc(sizeof(struct
> > > > property));
> > >
> > > How early is this running? If the allocator is set up by now,
> > > then this should use kzalloc()...
> >
> > It's running at the same time the device tree is created, so no, the
> > allocator isn't available yet.
> >
> > This isn't strictly a requirement, but it would be good to get
> > firmware hacks out of the way as early as possible, and it might as
> > well be done at the same time that the DT is created.
>
> Yes, you definitely want to get firmware fiddling done with as soon as
> possible. Certainly before anything starts relying on the device tree
> data.
>
> Another option (assuming OFW is still alive) is to as it to create the
> missing properties before extracting the tree. This is what we're
> currently doing in PowerPC.
OFW is indeed still alive. I don't have an opinion on that, I'll leave
it up to dsd to decide (once he's no longer busy with other stuff).
>
> >
> > >
> > > > +
> > > > + p->name = prom_alloc_string(name, NULL);
> > > > + p->value = prom_alloc_string(value, &p->length);
> > >
> > > ... which would also mean that kstrdup()/kmemdup() can be used
> > > here directly.
> > >
> > > > + prom_add_property(node, p);
> > > > +}
> > >
> > > This would be useful in common code. prom_create_property() might
> > > be a better name. It should also accept a length argument for the
> > > size of the data.
> > >
> > > > +
> > > > +/* Add dcon device as child of display */
> > > > +static void __init add_dcon_node(struct device_node *display)
> > > > +{
> > > > + struct device_node *node =
> > > > prom_early_alloc(sizeof(struct device_node));
> > > > + unsigned long flags;
> > > > +
> > > > + kref_init(&node->kref);
> > > > + node->name = prom_alloc_string("dcon", NULL);
> > > > + node->full_name = (char *) node->name;
> > > > + node->parent = display;
> > > > +
> > > > + write_lock_irqsave(&devtree_lock, flags);
> > > > + node->sibling = node->parent->child;
> > > > + node->allnext = allnodes;
> > > > + node->parent->child = node;
> > > > + allnodes = node;
> > > > + write_unlock_irqrestore(&devtree_lock, flags);
> > > > +
> > >
> > > This should be using the existing of_attach_node() function to
> > > link the node into the tree (in fact I know you've seen it
> > > because the above 6 lines are identical). :-) Also, there
> > > already exists a function "new_node" in
> > > arch/powerpc/platforms/iseries/vio.c that would be useful to move
> > > into drivers/of/base.c
> >
> > Is there any particular reason why OF_DYNAMIC needs to depend upon
> > PPC_OF?
>
> Only historical. Those functions can probably be brought out from
> under the OF_DYNAMIC protection... Bonus points for making pdt.c and
> fdt.c use it for linking nodes to the tree so that all methods are
> consistent. :-)
Done. I've done absolutely no testing of the flattree changes.
>
> It would also be useful to make the property linking code common for
> fdt.c and pdt.c
I can look at that and the new_node stuff later.
prev parent reply other threads:[~2011-03-10 2:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 17:12 [RFC 2/3] OLPC: add missing elements to device tree Daniel Drake
[not found] ` <20110304171235.10C1F9D401D-k/4jFdqg8LLlyo9zxV8I99HuzzzSOjJt@public.gmane.org>
2011-03-05 4:50 ` Grant Likely
[not found] ` <20110305045042.GH7579-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2011-03-05 17:23 ` Andres Salomon
2011-03-06 0:19 ` Grant Likely
[not found] ` <20110306001943.GB7467-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2011-03-10 2:51 ` Andres Salomon [this message]
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=20110309185125.0ca53221@queued.net \
--to=dilinger-pffuokh25lwstnjn9+bgxg@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.