From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 7AD411A0245 for ; Thu, 17 Jul 2014 09:12:25 +1000 (EST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id A1E521400B6 for ; Thu, 17 Jul 2014 09:12:24 +1000 (EST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Jul 2014 19:12:22 -0400 Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id B52216E801A for ; Wed, 16 Jul 2014 19:12:10 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s6GNCKqA5308786 for ; Wed, 16 Jul 2014 23:12:20 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s6GNCJQJ019280 for ; Wed, 16 Jul 2014 19:12:20 -0400 Message-ID: <53C706D2.7080207@austin.ibm.com> Date: Wed, 16 Jul 2014 18:12:18 -0500 From: Nathan Fontenot MIME-Version: 1.0 To: Grant Likely , Tyrel Datwyler Subject: Re: OF_DYNAMIC node lifecycle References: <53A30117.3010100@austin.ibm.com> <20140623144806.1348EC40A60@trevor.secretlab.ca> <53A9DB4F.9060708@austin.ibm.com> <20140625202446.77687C40AE6@trevor.secretlab.ca> <53AC7C2D.3040604@austin.ibm.com> <20140627124101.367F7C40E5E@trevor.secretlab.ca> <53AD8296.6040702@austin.ibm.com> <53C6C4BE.6010301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Cc: "devicetree@vger.kernel.org" , Pantelis Antoniou , Tyrel Datwyler , linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 07/16/2014 05:26 PM, Grant Likely wrote: > On Wed, Jul 16, 2014 at 2:57 PM, Grant Likely wrote: >> On Wed, Jul 16, 2014 at 12:30 PM, Tyrel Datwyler >> wrote: >>> On 07/15/2014 10:33 PM, Grant Likely wrote: >>>> I've got another question about powerpc reconfiguration. I was looking >>>> at the dlpar_configure_connector() function in dlpar.c. I see that the >>>> function has the ability to process multiple nodes with additional >>>> sibling and child nodes. It appears to link them into a detached tree >>>> structure, and the function returns a pointer to the first node. >>>> >>>> All of the callers of that function then call dlpar_attach_node(), >>>> which calls of_attach_node(). However, of_attach_node() only handles a >>>> single node. It doesn't handle siblings or children. Is this a bug? >>>> Does the configure connector ever actually receive more than one node >>>> at once? >>> >>> Yes, it is sometimes the case we will get a tree structure back of more >>> than one node. Under the proc interface implementation this just worked. >>> With the move to sysfs it appears we have a regression here. What makes >>> more sense here, for us to walk the tree calling of_attach_node, or to >>> move such tree walking logic into of_attach_node? From what I can tell >>> we are the only consumers of of_attach_node. >> >> That is very shortly going to change. The overlay code also uses >> of_attach_node(). I can make of_attach_node() recurse over >> descendants, but I'm also considering moving the powerpc code over to >> the of_changeset series that Panto and I are working on. >> >> Either way, the handling of multiple nodes should be common code. I >> think the easiest is to put the recursion into of_attach_node(), at >> least for fixing the bug. It can be reworked later. > > On pseries, do notifiers ever fail? ie. Does the reconfig code ever > object to a DT change and prevent it from being applied? > I cannot think of a time that I ever saw a notifier fail. -Nathan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Fontenot Subject: Re: OF_DYNAMIC node lifecycle Date: Wed, 16 Jul 2014 18:12:18 -0500 Message-ID: <53C706D2.7080207@austin.ibm.com> References: <53A30117.3010100@austin.ibm.com> <20140623144806.1348EC40A60@trevor.secretlab.ca> <53A9DB4F.9060708@austin.ibm.com> <20140625202446.77687C40AE6@trevor.secretlab.ca> <53AC7C2D.3040604@austin.ibm.com> <20140627124101.367F7C40E5E@trevor.secretlab.ca> <53AD8296.6040702@austin.ibm.com> <53C6C4BE.6010301@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Grant Likely , Tyrel Datwyler Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pantelis Antoniou , Tyrel Datwyler , linuxppc-dev List-Id: devicetree@vger.kernel.org On 07/16/2014 05:26 PM, Grant Likely wrote: > On Wed, Jul 16, 2014 at 2:57 PM, Grant Likely wrote: >> On Wed, Jul 16, 2014 at 12:30 PM, Tyrel Datwyler >> wrote: >>> On 07/15/2014 10:33 PM, Grant Likely wrote: >>>> I've got another question about powerpc reconfiguration. I was looking >>>> at the dlpar_configure_connector() function in dlpar.c. I see that the >>>> function has the ability to process multiple nodes with additional >>>> sibling and child nodes. It appears to link them into a detached tree >>>> structure, and the function returns a pointer to the first node. >>>> >>>> All of the callers of that function then call dlpar_attach_node(), >>>> which calls of_attach_node(). However, of_attach_node() only handles a >>>> single node. It doesn't handle siblings or children. Is this a bug? >>>> Does the configure connector ever actually receive more than one node >>>> at once? >>> >>> Yes, it is sometimes the case we will get a tree structure back of more >>> than one node. Under the proc interface implementation this just worked. >>> With the move to sysfs it appears we have a regression here. What makes >>> more sense here, for us to walk the tree calling of_attach_node, or to >>> move such tree walking logic into of_attach_node? From what I can tell >>> we are the only consumers of of_attach_node. >> >> That is very shortly going to change. The overlay code also uses >> of_attach_node(). I can make of_attach_node() recurse over >> descendants, but I'm also considering moving the powerpc code over to >> the of_changeset series that Panto and I are working on. >> >> Either way, the handling of multiple nodes should be common code. I >> think the easiest is to put the recursion into of_attach_node(), at >> least for fixing the bug. It can be reworked later. > > On pseries, do notifiers ever fail? ie. Does the reconfig code ever > object to a DT change and prevent it from being applied? > I cannot think of a time that I ever saw a notifier fail. -Nathan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html