[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <509D8C69.7060004@wwwdotorg.org>
Date: Fri, 09 Nov 2012 16:06:17 -0700
From: Stephen Warren <swarren@...dotorg.org>
To: Grant Likely <grant.likely@...retlab.ca>
CC: Pantelis Antoniou <panto@...oniou-consulting.com>,
Rob Herring <robherring2@...il.com>,
Deepak Saxena <dsaxena@...aro.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Scott Wood <scottwood@...escale.com>,
Tony Lindgren <tony@...mide.com>,
Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
Koen Kooi <koen@...inion.thruhere.net>,
linux-kernel <linux-kernel@...r.kernel.org>,
Felipe Balbi <balbi@...com>, Russ Dill <Russ.Dill@...com>,
linux-omap@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices
to mach-omap2)
On 11/05/2012 01:40 PM, Grant Likely wrote:
> As promised, here is my early draft to try and capture what device
> tree overlays need to do and how to get there. Comments and
> suggestions greatly appreciated.
Here's one other requirement I'd like that I don't think I saw
explicitly mentioned in your document:
Assuming a base file board.dts and a child board file child.dts, the
compiled file child.dtb should be usable with a modified board.dtb
assuming it exports the same set of attachment-points (hashed phandles,
socket objects, whatever). This allows bug-fixes etc. to board.dts
without forcing every child.dts to be recompiled.
If the attachment points is hashed node names or node content from
board.dts, I'm not sure how this is possible?
I suppose this is implicit if child.dtb can be used with either
board-a.dtb and board-b.dtb though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists