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