On Wed, Nov 18, 2015 at 1:05 PM, Brian Norris <computersforpeace@xxxxxxxxx> wrote: > (changing subject, add devicetree@xxxxxxxxxxxxxxx) > > On Tue, Nov 17, 2015 at 11:33:25PM +0100, Julia Lawall wrote: >> On Tue, 17 Nov 2015, Brian Norris wrote: >> > On Tue, Nov 17, 2015 at 06:48:39PM +0100, Julia Lawall wrote: >> > > Is this something that should be checked for elsewhere? >> > >> > I expect the same sort of problem shows up plenty of other places. I >> > don't think many people use CONFIG_OF_DYNAMIC, so the effects of these >> > failures probably aren't felt by many. The "problem" is non-existent because either CONFIG_OF_DYNAMIC is off or where it is used is limited (memory and cpus on PSeries) and now overlays. Overlays have the potential to be problematic, but we should manage ref counting for overlays in a completely different way. What that looks like, I don't know. I'll leave that to the person that cares about removing overlays. >> basically, this says that a structure field is initilized to a device node >> value, the structure is returned by the containing function, and the >> containing function contains no of_node_get at all. Certainly this is >> quite constrained, but it does produce a number of examples. I've got no idea if this is right or not. >> drivers/of/pdt.c, function of_pdt_create_node > > Not real sure about this one. SPARC. Stay away. > >> Any idea whether these need of_node_get? In all cases the device node >> value comes in as a parameter. > > I'm really not an expert on this stuff. I just saw a potential problem > that I happen to be looking at in other subsystems, and I wanted to know > what others thought. I think this discussion should include the DT folks > and the subsystems in question. For one, I'm as interested as anyone in > getting this todo clarified: > > Documentation/devicetree/todo.txt > - Document node lifecycle for CONFIG_OF_DYNAMIC Step 2 after figuring out it can't be documented is "define a new way to handle dynamic DT refcounting aka how to get rid of of_node_get/put." Rob -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
