On Wed, Jul 16, 2014 at 2:57 PM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: > On Wed, Jul 16, 2014 at 12:30 PM, Tyrel Datwyler > <turtle.in.the.kernel@xxxxxxxxx> 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? g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
