All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Bohan <mbohan@codeaurora.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: David Daney <ddaney@caviumnetworks.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	linux-kernel@vger.kernel.org, grant.likely@secretlab.ca,
	rob.herring@calxeda.com, ralf@linux-mips.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	david.daney@cavium.com, linux-arm-msm@vger.kernel.org,
	Pantelis Antoniou <panto@antoniou-consulting.com>
Subject: Re: [PATCH] of/lib: Export fdt routines to modules
Date: Thu, 17 Oct 2013 19:54:06 -0700	[thread overview]
Message-ID: <20131018025405.GA3722@codeaurora.org> (raw)
In-Reply-To: <52608457.5040609@roeck-us.net>

On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
> On 10/17/2013 04:51 PM, Michael Bohan wrote:
> >On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> >>Still, what prevents you from unflattening it and just using the
> >>normal device tree functions as David suggested ?
> >
> >I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
> 
> Yes, that was the idea.
> 
> >That's an interesting thought. I was planning to scan the fdt
> >only once and populate my own structures, but I suppose I could
> >use the of_* APIs equivalently.
> >
> >It seems there are some problems though.  of_fdt_unflatten_tree()
> >does not return errors, and so for the purposes of my driver it
> >would not be sufficient to detect an invalid firmware image.
> >
> It does so, at least partially. If there is an error, it won't set
> the nodes pointer. Granted, that is not perfect, but it is at least
> a start. Ultimately, I considered it 'good enough' for my purpose
> (for devicetree overlays - see [1] below), as any missing mandatory
> properties or nodes are detected later when trying to actually read
> the properties. In my case, I also have a couple of validation
> properties to ensure that the overlay is acceptable (specifically
> I use 'compatible' and 'assembly-ids', but that is really a detail).

That's certainly better than nothing, but I think it would be
useful to make a distinction between a malformed fdt and a fdt
that's simply missing the right information. Without error
codes, I think we lose this aspect.

> >Would people entertain changing this API
> >(and implicitly __unflatten_device_tree) to return errors? I'm
> >guessing the reason it's coded that way is because the normal
> >usecase is 'system boot', at which time errors aren't that
> >meaningful.
> >
> >Also, there's no way to free the memory that was allocated from
> >the unflatten process. May I add one?
> >
> 
> The patchset submitted by Pantelis Antoniou to add support for
> devicetree overlays adds this and other related functionality.
> See [1], specifically the patch titled "OF: Introduce utility
> helper functions". Not sure where that is going, though.
> It may need some cleanup to be accepted upstream.
> Copying Pantelis for comments.
> Guenter
> 
> [1] https://lkml.org/lkml/2013/1/4/276

Thanks. So it seems that Pantelis's __of_free_tree() is what I'm
looking for.

Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-10-18  2:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16 23:27 [PATCH] of/lib: Export fdt routines to modules Michael Bohan
2013-10-16 23:39 ` David Daney
2013-10-16 23:39   ` David Daney
2013-10-17  0:27   ` Michael Bohan
2013-10-17  4:54     ` Guenter Roeck
2013-10-17 23:51       ` Michael Bohan
2013-10-18  0:44         ` Guenter Roeck
2013-10-18  2:54           ` Michael Bohan [this message]
2013-10-18 13:28             ` Pantelis Antoniou
2013-10-18 15:57               ` Rob Herring
2013-10-18 16:16                 ` Guenter Roeck
2013-10-18 16:30                 ` David Daney
2013-10-18 16:30                   ` David Daney
     [not found]                   ` <52616228.80002-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2013-10-18 19:32                     ` Michael Bohan
2013-10-18 19:32                       ` Michael Bohan
     [not found]                       ` <20131018193229.GA30141-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-10-18 21:20                         ` Rob Herring
2013-10-18 21:20                           ` Rob Herring
2013-10-19  1:49                           ` Michael Bohan
2013-10-19  3:41                             ` Guenter Roeck
2013-10-18 18:38           ` Mark Rutland
     [not found]             ` <20131018183804.GA8546-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-10-19  1:41               ` Michael Bohan
2013-10-19  1:41                 ` Michael Bohan

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=20131018025405.GA3722@codeaurora.org \
    --to=mbohan@codeaurora.org \
    --cc=david.daney@cavium.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ddaney@caviumnetworks.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=panto@antoniou-consulting.com \
    --cc=ralf@linux-mips.org \
    --cc=rob.herring@calxeda.com \
    /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.