On 07/16/2014 05:26 PM, Grant Likely wrote: > 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? > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
