From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [PATCH 8/9 V3] Add documentation for the new DTS language. Date: Tue, 2 Mar 2010 15:20:41 +1100 Message-ID: <20100302042040.GK23435@yookeroo> References: <20100222013004.GM29038@yookeroo> <9696D7A991D0824DBA8DFAC74A9C5FA305B2021A@az33exm25.fsl.freescale.net> <4288fc0b-79a4-42fd-9e77-573dbad79210@SG2EHSMHS004.ehs.local> <4B8C2C4C.8070901@freescale.com> <4B8C44C8.6000105@freescale.com> <20100302011928.GG23435@yookeroo> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Grant Likely Cc: Wood Scott-B07421 , devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, Yoder Stuart-B08248 , Scott Wood , Jeremy Kerr , John Williams List-Id: devicetree@vger.kernel.org On Mon, Mar 01, 2010 at 07:16:57PM -0700, Grant Likely wrote: > On Mon, Mar 1, 2010 at 7:10 PM, Grant Likely = wrote: > > On Mon, Mar 1, 2010 at 6:19 PM, David Gibson > > wrote: > >> On Mon, Mar 01, 2010 at 04:50:48PM -0600, Scott Wood wrote: > >>> Grant Likely wrote: > >>> >On Mon, Mar 1, 2010 at 2:06 PM, Scott Wood = wrote: > >>> >>Hmm, I'd think it would be useful to e.g. include a template and > >>> >>subsequently modify it within the same node, rather than a more ver= bose and > >>> >>error-prone process of referencing labels later. > >>> >> > >>> >>If sequential operations within a tree are supported, I'm not sure = that > >>> >>there's any remaining need for separate top-level trees -- you coul= d express > >>> >>the same thing as top-level property/node redefinitions. > >>> >> > >>> >>What are the problems with supporting this? > >>> > > >>> >The main problem is that it doesn't fit the use cases I need to solv= e. > >>> > I need to start with a 'stock' or 'vanilla' tree, and then add into > >>> >it board details. =A0ie. lay down a generic MPC5200 tree (include a = .dts > >>> >file), and then fill it in with i2c and spi devices. =A0Or include t= he > >>> >.dts file generated by the XIlinx FPGA toolchain, and then populate = it > >>> >with board details. =A0Sequential operations within the tree doesn't= do > >>> >anything to support this use case because the board level fixups will > >>> >be applied all over the tree. > >>> > > >>> >To reverse the question, what is the use case that is best solved wi= th > >>> >sequential operations within the root tree? > >>> > >>> The case I had in mind was having includable templates for fragments > >>> of the tree, rather than starting with a generic full tree. =A0Though > >>> I'd probably end up wanting things like template arguments and math > >>> as well (is any existing macro language going to do cell > >>> arithmetic?), > >> > >> m4 can do arithmetic, but it's pretty hideous. =A0But I still have > >> allowing expressions as a reasonable extension within dtc itself. > >> Macros or templates with parameters raise a lot more complex issues. > >> > >> [snip] > >>> >>If you don't reuse the label, but bar is redefined, where does bar-= label > >>> >>point? > >>> > > >>> >It doesn't point to anything because when a property is deleted, the > >>> >label also goes away. > >>> > >>> Is it the same way with node labels? > >> > >> Yes, node labels are attached to the node, so if the node is removed, > >> so is the label. > >> > >>> What happens to previous > >>> references? =A0Is it detected by dtc, or does a bad phandle/path stick > >>> around to be found at runtime? =A0And what if the node is added back? > >> > >> References aren't resolved until the whole tree is built. =A0So > >> references will always resolve to the *last* definition of a label, > >> and if the last "definition" is an undefinition / deletion, then the > >> references will fail to resolve and give an error. > > > > ...except for when processing node redefinitions by label in the curren= t patch. > = > In fact, I think this has to be the case, otherwise it would be > possible to create circular references in node redefiniton. Ah, yes. Node redefinition references act in order with the labels. Which is a potentially nasty inconsistency. Ugh. -- = 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