From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Mack Date: Fri, 26 Oct 2012 09:24:11 +0200 Subject: [U-Boot] Merging device trees at runtime for module-based systems In-Reply-To: <20121026005319.GI7222@truffula.fritz.box> References: <5087B919.2010006@gmail.com> <20121025124441.6D75A2005C0@gemini.denx.de> <50893633.6070408@gmail.com> <20121025204632.CFD132005C3@gemini.denx.de> <20121026005319.GI7222@truffula.fritz.box> Message-ID: <508A3A9B.50804@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 26.10.2012 02:53, David Gibson wrote: > On Thu, Oct 25, 2012 at 10:46:32PM +0200, Wolfgang Denk wrote: >> Dear Daniel, >> >> In message <50893633.6070408@gmail.com> you wrote: >>> >>> Overwrites must be addressed in the first place. The most common example >>> is that a more generic part (the module tree) registers all details >>> about a peripheral up-front but then sets its status to 'disabled'. That >>> way, the more specific part (the base board tree) can overwrite this >>> property to 'okay' at wish to enable it and not care for the pre-defined >>> details. This is also how we do things in our device-trees. >> >> Agreed. >> >>>> I definitely can see the benefit of such a feature and would be happy >>>> if you could go forward and implement it. >>> >>> Ok then. I guess this should be something that can eventually be merged >>> back into libfdt? >> >> I can't speak for the FDT custodian, but I think this makes a lot of >> sense. > > As a rule I'm happy to see more functionality for libfdt. I've only > seen bits and pieces of this thread, though, so I'd need to see a > summary of what exactly is being proposed. That's strange, as I copied you from the very first posting. Anyway, here's the archive: http://lists.denx.de/pipermail/u-boot/2012-October/138227.html I would especially like to know where such a new functionality should live, which data types it should operate on and what would be an appropriate name for it. Many thanks, Daniel