From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Rowand Subject: Re: [PATCH 1/2] fdt: Allow stacked overlays phandle references Date: Thu, 13 Jul 2017 12:35:37 -0700 Message-ID: <5967CB89.7020907@gmail.com> References: <1497451946-15443-1-git-send-email-pantelis.antoniou@konsulko.com> <1497451946-15443-2-git-send-email-pantelis.antoniou@konsulko.com> <20170703090648.GV13989@umbus.fritz.box> <1499085674.4225.17.camel@hp800z> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1499085674.4225.17.camel@hp800z> Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Pantelis Antoniou , David Gibson Cc: Tom Rini , Nishanth Menon , Tero Kristo , Rob Herring , Simon Glass , Devicetree Compiler , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On 07/03/17 05:41, Pantelis Antoniou wrote: > Hi David, > > On Mon, 2017-07-03 at 19:06 +1000, David Gibson wrote: >> On Wed, Jun 14, 2017 at 05:52:25PM +0300, Pantelis Antoniou wrote: >>> This patch enables an overlay to refer to a previous overlay's >>> labels by performing a merge of symbol information at application >>> time. >> >> This seems to be doing things the hard way. >> > > It is the minimal implementation to get things to work, with the current > overlay implementation. I do have plans for a version 2 with fixes to > a number of areas. > >> You're essentially extending the semantics of overlay application to >> add the symbol merging. You've implemented these extended semantics >> in libfdt, which is all very well, but that's not the only overlay >> application implementation. >> >> > > This is a port of the same patch that's against the linux kernel. > As far as I know there's no other implementations, or at least none > that are open source. That patch never made it into the kernel. I submitted a different patch last week (now at v2, probably soon to be v3, then probably v4 when 4.13-rc1 comes out), so hopefully we will get the overlay symbol loading support into the kernel soon. >> It seems to me a better approach would be to change dtc's -@ >> implementation, so that in /plugin/ mode instead of making a global >> __symbols__ node, it puts it into the individual fragments. That way >> the existing overlay application semantics will update the __symbols__ >> node. >> > > A lot of things can be made better, on the next version. These are > minimally intrusive patches to address user requests for the current > implementation. > > Why don't we start by making a list, and work towards that goal? > > Care to start about what you want addressed and how? > > Regards > > -- Pantelis > >