From: David Gibson <david@gibson.dropbear.id.au>
To: Jon Loeliger <jdl@freescale.com>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] Remove bogus errors from check_chosen.
Date: Sat, 24 Mar 2007 10:51:53 +1100 [thread overview]
Message-ID: <20070323235153.GG4459@localhost.localdomain> (raw)
In-Reply-To: <1174665793.32390.73.camel@ld0161-tx32>
On Fri, Mar 23, 2007 at 11:03:13AM -0500, Jon Loeliger wrote:
> On Fri, 2007-03-23 at 10:05, Scott Wood wrote:
> > On Fri, Mar 23, 2007 at 02:31:58PM +1100, David Gibson wrote:
> > > I'm not 100% comfortable with this patch; I'd like for dtc to have the
> > > facility to do more-or-less complete tree validation.
> >
> > That'd be nice as long as it's optional; it should be possible to do a
> > low level dts->dtb transformation without the tool assuming that the
> > output is intended to be a final, valid tree with the specific bindings
> > that dtc knowns about (or even an OF-ish tree at all).
> >
> > -Scott
>
> So, how about adding a "--complete" or "--final"
> sort of flag an having it:
>
> - Enforce presence of /chosen
> - Disallowing the proposed [ ? ? ? ? ] indicators
> - Uh, other stricter checking...
I was thinking of having three basic levels of checking:
- syntactic structure
Checks on the structure of the flat tree: duplicate property / node
names, invalid characters in names and other such basic errors. This
would be on, and fatal by default.
- semantic structure
Checks on the content of nodes: linux,phandle #a and #s properties
have the right size, reg properties match the corresponding #a and #s
nodes, properties which reference phandles contain a valid phandle,
properties supposed to contain strings actually do. This would be on
by default. It would be fatal by default when generating a dtb or asm
from dts, but not in the other direction.
- kernel requirements
Checks this is a complete tree with all the bits that the kernel
needs: /chosen is present, /memory is present and valid, cpu nodes
have the required cache size information etc. This would only be on
if requested.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2007-03-23 23:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 16:11 [PATCH] Remove bogus errors from check_chosen Scott Wood
2007-03-22 16:22 ` Scott Wood
2007-03-23 3:31 ` David Gibson
2007-03-23 15:05 ` Scott Wood
2007-03-23 15:21 ` Jerry Van Baren
2007-03-23 15:36 ` Scott Wood
2007-03-23 15:48 ` Jerry Van Baren
2007-03-23 23:42 ` David Gibson
2007-03-23 23:40 ` David Gibson
2007-03-23 16:03 ` Jon Loeliger
2007-03-23 23:51 ` David Gibson [this message]
2007-03-26 13:35 ` Jon Loeliger
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=20070323235153.GG4459@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=jdl@freescale.com \
--cc=linuxppc-dev@ozlabs.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.